I need to enable SSO between my customer's website and my API.
The customers website doesn't use Auth0 but allow users to login using a few different social providers like Microsoft and Google.
My API is secured using Auth0 and also supports Microsoft and Google authentication via Auth0. If my customer sends the JWT token received when the user authenticated with Google with their request to my API, will Auth0 authenticate the user even though my customer doesn't use Auth0?
Google/Microsoft auth is OAuth. OAuth is an explicit grant between the user and one particular application. It cannot and won't be shared with your app. The user would need to do a separate OAuth flow with your application to grant it access. There is no way around that.
However, given that this is an API, the more likely scenario is that the user shouldn't auth with your app at all, but rather, it should be the customer's application that auths and then works on behalf of the user. As such, you'd just set up the customer's application as a client and given them client credentials to use. Then, the user auths with the customer's website, the customer's website auths with your API via its client credentials, and then the user in effect works with your API via the customer's application as a go-between.
No , if your api application is protected by Auth0 and use external providers , after authentication from external providers and back to Auth0 , Auth0 will validate the token issued by external provider ,decode token , read claims , issue Auth0's own token and implement session management . So that your api application only accepts tokens which issued by Auth0 and validate tokens use Auth0's key-pairs , it won't accept other provider's tokens .
You can make your client application and api application both secured by one identity provider(Auth0/Google/Microsoft) .
Related
I have followed a few guides on adding authentication to my vue application (which has a net core api backend).
https://medium.com/dev-bits/a-guide-for-adding-jwt-token-based-authentication-to-your-single-page-nodejs-applications-c403f7cf04f4
and
http://jasonwatmore.com/post/2018/08/14/aspnet-core-21-jwt-authentication-tutorial-with-example-api
I'm a junior programmer with authentication so forgive me if my questions seem dumb.
These involve sending a username and password to my api login method and getting back a jwt token (is this an id_token or an access token?). I then send this token with every api request using the Bearer authorization. Some guides (eg microsoft net core docs) have this jwt token include role information.
Is this just a basic form of jwt authentication. Some things i have read about token authentication indicate that when i login i should get an id token which i then exchange for an api access token. These tutorials don't appear to do that - it looks like there is only one token and that it's used for api access and authentication.
Ideally i would like to implement oidc into my vue application but the many guides out there dont seem to address this.
The tutorials are talking about the JWT token based authentication , it will issue a JWT token to declare a user and their access permissions in the application.
When a user tries to log in to the application with their username and password, the server/api side will authenticate the user ,generate the token and send token back to client . Next time client could use token to access the server/API which eliminates the need for the app or system to remember or store the user’s credentials. You can involve user's basic profile information(not sensitive) and some custom claim in that token such as claim related to roles . Both client side and server side should check the specific role if you want to check the authorize part .
Id_token was added to the OIDC specification(OpenID Connect) as an optimization so the application can know the identity of the user, without having to make an additional network requests. It contains user profile information (like the user's name, email, and so forth) , and So if you are using OpenID Connect (Implicit Flow is suitable for SPA) to do the authentication and authorization , you will get id token which identity of the user , and access token which could be used to access the protected resource/API .
You are not using OpenID Connect , so no id token is involved in the scenario .
according to here (https://oauth.net/articles/authentication/) and many other things I have come across. OAuth is not meant to handle end user authentication. Reading through the article above and others while searching provides so much information at once from so many angles that it is hard to see through it all. ok...
Does this mean that...
A) The protocol itself is not intended to handle authentication, so therefore, OAuth client apps should inspect "who" can authorize users according to the OAuth providers?
If ONLY the user can authorize third party apps, then isn't the fact of receiving authorization from the OAuth provider in itself proof of authentication? (if this is the case, then can OAuth access tokens from places like Google and Facebook be trusted as authentications?)
B) OAuth client apps cannot trust authenticating users with OAuth, so therefore must provide another sound authentication mechanism alongside it?
If this is the case, then every site that I have clicked "Login With [provider]" (and no other complementary authentication scheme) has got authentication wrong?
It seems to me that if only trusted and specific OAuth providers are used, then this flow could infer authentication
App requests login with trusted providers
User is directed to provider to authorize (ONLY user can authorize)
App then requests and receives token from provider, and adds user to the app database if necessary.
Token is put into secure cookie or JWT and returned to the user to be presented on subsequent visits.
The purpose of OAuth2 access token is to delegate some access rights (scopes) from a user to a client application. So the application redirects the user to an authentication provider (OAuth2 server), which authenticates the user and asks the user (consent step) whether he/she wants to delegate some access rights (the scopes requested by the application) to the application.
If a client application receives an access token, it can get its meta data at the OAuth2 introspection endpoint - such as username of the user (resource owner). So this way, the OAuth2 can be used for authentication. But the main purpose of access tokens is to delegate some rights. For example if a third party application wants to save its data to a user's Google Drive, it needs an access token issued by Google with scopes that allow it to access Google Drive.
If you want to use OAuth2 only for authentication in your client application (to get identity of a user), you can use OpenId Connect (OAuth2 extension) and its ID token, which is in JWT format and contains information about the user that was authenticated the authentication provider. This is better suited for the "Login With ..." functionality.
I'm implementing Facebook and Google SSO on my website using custom workflow (redirect urls, parsing on server side etc. - no javascript) and I got to the point I have access_token, token_type and expires_in and from Google also id_token and I am confused what to do next to authenticate the user.
I read a little about authorization vs authentication, and that Facebook and Google SSO is OAuth2 which provides authorization, but not authentication, from which I understand that this way my web application is authorized to do something on behalf of the user, but I cannot be sure the user is the one who I think he is? My main source is this: OAuth Authorization vs Authentication
So, my question is, what should I do to be able to can consider the user logged in.
Thank you
In your case google (and facebook) is authenticators. This services just tells your application that user who try to login to your system is the one who he wants to appear.
Assume you differentiate users by unique email.
Your application flow should be next:
The user try to login to application using google Application do all redirection google flow stuff and gives you tokens
Application need to store this tokens for future use
Application check if this user's email presented in database
If email is presented and google returns tokens (google authenticate your user successfully) you can login user in your app
If email isn't presented in database but google authenticate user successfully you can store this user (with email) to your database - sign it up - this is new user in your system
Same flow with Facebook. Surely you can extend this logic to be more your application specific.
SSO and OAuth are different. OAuth is authorization protocol.
You are dealing Google and Facebook oauth.
OAuth
In case of oauth, after successful authentication(google/facebook) you will get access token. You can use token for maintaining the user session.
With this token user is authorized, Now you should check whether the user is present in your database, if yes then authenticate the user and redirect to your application.
SSO
SSO is user authentication service. There are way to implementing SSO like kerberos SSO, ADFS SSO.
We should never use OAuth2 access token for authentication.
For details, please refer
https://oauth.net/articles/authentication/
The OpenIDConnect, built on top of OAuth2, can be used for authentication.
Google supports OpenIDConnect
https://developers.google.com/identity/protocols/OpenIDConnect
The basic idea is Google will issue the client app (your application) a ID Token after the user has login his Google account. You can then extract user information (e.g. email, unique user id) from this ID token and proceed your login flow.
Our system architecture has this setup. We have an API that is used by a WebApp Client. We allow users to authenticate using an Identity Provider (IDP) that returns SAML.
The problem is how would you setup authentication? Which of the flow below would be more suitable?
WebApp Client controls the flow
When a user needing authentication visits WebApp Client, redirect user to IDP.
User authenticates with IDP
IDP redirect user back to webapp client with SAML response
WebApp client passes the SAML to the API.
The API will decrypt and read the attributes.
API then gives access token to the WebApp client it can use for subsequent requests.
API controls the flow
When a user needing authentication visits WebApp Client, redirect user to a special endpoint of API.
API redirects user to IDP
User authenticates with IDP
IDP redirect user back to API with SAML response
API decrypt and read the attributes
API redirects user to the WebApp client passing an access token to the WebApp client it can use for subsequent requests.
I'm currently asking myself the same questions with google idp. I thought about passing the returning code from idp to my API and then authenticating the user from my API.
If you have some return on your experience let me know :)
I need to implement an authentication mechanism with JWT tokens for an mvc web application and a mobile application as well. Users will be able to register to our database and authenticate by using credentials (from signup) or use facebook single sign on. Both applications will use web API for data exchange with JWT token. I am thinking of using Identity Server 3 for that using Resource Owner Flow and i have some questions on that:
1) User will login from mobile application and will get a jwt token. Mobile application will verify it's validity and will refresh when needed. In order for mobile application to have user always logged in should i store refresh_token on device??? Is it secure?
2) I cannot understand how am i going to handle facebook authentication and get jwt token from identity server. Should i first get users email from facebook profile data and then what???
Thank you
1- You can store refresh token in database( identity server provide a token stor)
also you can use third party library to store tokens in device securely.
2-To use the 3rd party logins you need to do the redirect style to the IdSvr login page. Using resource owner password flow means you miss out on all the features in the token service like SSO, 2fa and federated authentication.