How to share auth0 authentication information between 2 different APIs? - javascript

Pretty much new on APIs and microservice world.
i am using auth0 for authentication.
I have a convert express API POST endpoint which will only work if the user is authenticated, however for frontend -> ( home page, login button, login from auth0 callback, redirection) I using different api Homepage express api.
After user logs in from homepage api, from his profile dashboard user tries to send a post request to convert API endpoint this doesn't work and throws an error check.state argument is missing.
How do I make sure if one API authenticates that authentication information should be shared with another API endpoint which needs authentication?
app.use(‘/authUrls’,requiresAuth(),authUrlsRouter) //convert api post request

This may be an assumption, but it appears that you are creating a regular web application with Node.js, and what you want is authentication per session, not per API endpoint. This quickstart from Auth0 walks through it nicely. It uses Passport.js and express-session to provide middleware.
As per the tutorial:
In a typical web application, the credentials used to authenticate a user are only transmitted during the login request. If authentication succeeds, a session is established and maintained via a cookie set in the user's browser. Each subsequent request does not contain credentials, but rather the unique cookie that identifies the session.
How it works: when the login api is called and completed successfully, the user's authentication is stored in that session. Whenever other API's are called that require an authenticated user, you can just include the middleware (in the quickstart it is called 'secured'): it will query that respective session's data and allow / disallow based on the user's authentication status.
For example, the convert endpoint:
router.post('/convert', secured(), this.convertfunction);
And a non-auth endpoint:
router.get('/other', this.otherfunction);
The full tutorial has much more information available. But this illustrates how middleware will solve your problem.

Related

Silent SAML Authentication using Auth0 as Identity Provider

What I'm trying to do is a Silent Authentication with Auth0 as Identity Provider using SAML 2.0 protocol. I don't want to use the Auth0 SDK because the purpose of the Server Provider is to be able to change between Identity Providers. I have read this post and this other.
I updated my login url from
https://{your_domain}.auth0.com/samlp/{client_id}
to
https://{your_domain}.auth0.com/samlp/{client_id}={connection your_db_connection_name}
As mentioned in the first link, but this only allow me to avoid redirections if the user has already an existing session. The second link refers to a parameter in the url:
prompt = none
But this is for OpenId Connect protocol, so I doesn't help me.
The current flow is the following:
User send credentials to my Server Provider (this is useless because
Auth0 requires the credentials in his widget)
The Server Provider requests for SAML authentication to Auth0
Auth0 redirects the user to his login Widget (the user enters the
credentials again)
The user get access
What I want to achieve is:
User send credentials to my Server Provider
The Server Provider Integrates the credentials (here is where I do
not know how) in the SAML 2.0 request
Auth0 receive and authenticate the credentials (without any kind of
redirection)
The user get access
What I'm using:
As Server Provider, Node JS with Express and saml2-js library
As Identity Provider, a Regular Web Application with the SAML2 Web App add-on on Auth0
I am new using SAML and Auth0 and I do not know much yet. Any guide or advice is welcome. Thank you.
(If I have flaws in my English, do not hesitate to comment, thanks)
I have researched about this and discovered that it is not possible to achieve it (not now, perhaps in the future).
The use of HTTP-Post Binding allows to avoid redirection only if a user session already exists. If not, the user will be redirected to the IdP login page (in this case, the login page of Auth0)
There is a profile in the SAML protocol and it is called Enhanced Client or Proxy (ECP), but it is rarely used and recommended for applications that can't use the browser.
Also, only some IdPs support it, like Keycloak and Shibboleth.

Get user Access Token from Twitter in Angular 2+ app

Hi I want to get a twitter user access token/refresh token so that My application can post/read tweets on behalf of the user..
I have a button in my app.. on clicking of the button, I need to show something like below image -
user should be able to provide his/her credential and if it is already logged in to twitter then he/she should only see authorize app button..
I created a new app in my developer twitter account.. but little clueless on how to get user's access token to post/read behalf of him...
Twitter uses OAuth1.0a unlike Facebook which uses OAuth2.0. The difference between OAuth1.0a and OAuth2.0 is that OAuth1.0a is more secure and you should use a server-based authentication flow because it involves api keys and secrets which we shouldn't be sharing with angular app.
On server side (NodeJS/Django, etc) you should use a client library for OAuth1.0 which will help you in complicated process of signing requests befores sending it to twitter.
Here is a useful link (which I also used) for you to implement the server flow:
https://github.com/requests/requests-oauthlib/blob/master/docs/oauth1_workflow.rst
Basically, the OAuth flow for twitter is as follows:
Send a POST request to oauth / request_token
You will get the authroization url from Step 1 like this https://api.twitter.com/oauth/authorize?oauth_token=XXX which you will redirect the user to so that they can authorize your app
Twitter redirects the user to your redirect url (which you sent with the request in previous step) with access_token and verifier.
You need to exchange the access_token and verifier for the actual usable user access token by sending a POST to oauth/access_token.
You can find more details for 3-legged OAuth flow here: https://developer.twitter.com/en/docs/basics/authentication/overview/3-legged-oauth

Consume Saml Response from external identity provider

I am having trouble configuring my application to consume the SAML response from an external identity provider (in this case, OneLogin). My application has a javascript (angular5) front-end and .NET back-end.
Here is our current work-flow when using our own identity provider and service provider.
User navigates to our application in the browser and receives a 401 unauthorized when requesting resources from the API.
User is redirected to the login page.
User enters credentials which are posted to our server-side identity provider.
If the user is authenticated, the identity provider returns a SAML response to the client.
Client posts the SAML response to the service provider.
Service provider returns the tokens needed to access the rest of the API.
Now a customer has requested we integrate their external identity provider using OneLogin. Here is what I understand to be the new workflow.
User navigates to our application in the browser and receives a 401 unauthorized when requesting resources from the API.
User is redirected to the OneLogin (external identity provider) page.
User enters credentials which are authenticated by OneLogin.
OneLogin will post to our provided service provider endpoint with the SAML response as Form Data in the HTTP Post.
If post is successful the user will be redirected to any url provided when configuring OneLogin.
?????? (Our front-end still has no idea who the user is or whether or not they are authenticated).
Currently, all communication between our angular front-end (client) and .NET back-end (server) is initiated by the client. What I really need is for the client to receive that SAML response form data that is posted by OneLogin, so that I can initiate authorization with our service provider and receive the appropriate response in the client, but from what I understand I won't be able to consume the Form Data client side. I was hoping I could have the external identity provider redirect to a page on our front end and encode that saml response as a query parameter, but I am not seeing any way to do that.
I feel like there is something I am missing, but all the OneLogin examples seem to be the OneLogin identity provider communicating with a server side service provider and no mention of the client side. I could use some help better understanding what I need to do to accomplish my goal of informing the client that the user is authenticated and authorized.
What you describe with OneLogin is the SAML2 Web Browser SSO profile. As you see, it's all done through the browser. The user gets redirected from the client to the IdP, where they login. The IdP then POSTs a SAMLResponse to your Attribute Consumer Service (ACS) URL at your back end. It's the ACS's job to decode the SAMLResponse and parse the SAML2 attributes contained within it. It can create a new session at that point if required.
At this point the back end now knows who the user is. So you can initiate another redirect to send the browser to another URL with a parameter that lets the client know it has to retrieve user details from the back end. Perhaps some sort of /sso?token=something URL. The client side can then ask the back end to return JSON perhaps that contains the user information referenced by token, i.e. a session of some sort the back end has created once the attributes have been verfied.

Youtube analytics example: Keep google account signed in

I'm working with this Oauth2 example from Youtube API's documentation: https://developers.google.com/youtube/v3/code_samples/javascript?hl=es-419
The problem is: every time I execute a request it asks me for sign in with a google account.
The question is: how can I keep the user signed in? With long access token or something like that.
I'm working with a laravel app.
Thanks in advance.
You need to implement OAuth 2.0 Authorization.
The YouTube Data API supports the OAuth 2.0 protocol for
authorizing access to private user data. The list below explains some
core OAuth 2.0 concepts:
Here are some important points from YouTube API.
When a user first attempts to use functionality in your application that requires the user to be logged in to a Google Account or YouTube
account, your application initiates the OAuth 2.0 authorization
process.
Your application directs the user to Google's authorization server. The link to that page specifies the scope of access that your
application is requesting for the user's account. The scope specifies
the resources that your application can retrieve, insert, update, or
delete when acting as the authenticated user.
If the user consents to authorize your application to access those resources, Google returns a token to your application. Depending on
your application's type, it either validates the token or exchanges it
for a different type of token.
For example, a server-side web application exchanges the returned
token for an access token and a refresh token. The access token lets
the application authorize requests on the user's behalf, and the
refresh token lets the application retrieve a new access token when
the original access token expires.
Note: Important: You need to obtain authorization credentials in the Google Developers Console to be able to use OAuth 2.0
authorization.
Follow the steps in this documentation to obtain authorization credentials.
Your application must have authorization credentials to be able to use
the YouTube Data API. This document describes the different types of
authorization credentials that the Google Developers Console
supports. It also explains how to find or create authorization
credentials for your project.

OAuth 2.0 token handling. Is there a Server token and client token?

I have a problem understanding the principle handling of oauth 2.0 tokens.
My scenario is, I have a web based frontend backend system with node.js and angular 2.
A user should be able upload a video on this site. Then some additional metadata is created (dosen't matter for this question). When that is done, the user could upload the video to youtube with the additional data by clicking on a button.
My question is how many tokens/credentials are there in this process. The youtube api needs an oauth token. Does the user also have its own token?
Here is the tutorial I used:
https://ionicabizau.net/blog/14-uploading-videos-to-youtube-using-nodejs
As you can see one token for the API is created for local testing. But is this token generated in a different way in a live version? And how is the user of my website recognized. Also via this token? Or do I have to generate a second token for him?
I am not sure what you mean by 'Token'.
In order to access any Google API you will first need to register your application on Google Developer console. You will then need to create Oauth2 credentials. Oauth2 credentials is were your application will request access from a user to access the data on their YouTube account.
On Google Developer console you will need to save the Client id, client secret and the redirect uri. All three will be needed by your code to authenticate the user.
When the user grants your application access to their YouTube data. You will get an access token and a refresh token back from the authentication server. Access tokens are short lived about an hour and are used to make requests (like upload) to the API. A refresh token can be used to request a new access token once the one you have currently has expired.
You will probably end up with the following:
client id, client secrete, redirect uri, and a refresh token.
If you are interested I have a tutorial that is part of my Google Development for beginners tutorial series that explains Oauth2 and how it works.
An access token is generated from the Server side and sent back to client from where the access request is generated. For all the subsequent requests you need to pass the access token which will be verified with the signature of the token saved on the server to check the authentication of valid requests. You will only get 1 access token which will be used.
You can also use "Refresh" tokens in case you need to keep your access tokens valid for longer duration.

Categories

Resources