The spec says
3.1.2.3. Authorization Server Authenticates End-User
The methods used by the Authorization Server to Authenticate the End-User (e.g. username and password, session cookies, etc.) are beyond the scope of this specification.
How does SSO work with OpenID Connect?
Are cookies used? Is "id_token_hint" used?
I could not find anything about it.
Its implementation specific, but typically when you login at the authorization server, you receive a login session cookie with the server that is used to give you the SSO experience.
You can use the id_token_hint to pass your ID-token when you authenticate with a new app to get a more smooth login experience.
Related
Is it possible to log user out of only a single client? I tried to search online but could not find anything for logging user out from only a specific client.
With OAuth2 authentication, you don't log in or out of an application. OAuth2 is about permission delegation using access tokens. There is also the single sign on (SSO) feature of OpenID Connect (OAuth2 extension).
So you can either log out of the SSO session, which will force you to enter your credentials on the next /auth request. Or you can revoke a token used by a client. But if you have a valid SSO session at the auth server, the client can request a new token without you entering credentials.
So I think you will need to change your requirements (for logging out) to be compatible with OAuth2 / OpenID Connect concepts.
I don't quite figure out why oauth2 is for autheorization and OpenID Connect is for authentication purposes.
From OAuth2 RFC
authorization server
The server issuing access tokens to the client after successfully
authenticating the resource owner and obtaining authorization.
By other hand, according Authorization Code Flow RFC Agent or relying party is redirected to a some kind of authentication page in order to be able to authentication user, doesn't it?
Moreover, I've always read that OpenID Connect in built on Oauth2 in order to provide authentication mechanism to Oauth2. Is it right?
OAuth2.0 is an authorization protocol. OpenID Connect incorporates id tokens to add authentication on top of it
authorization server The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
Here the authentication is done for the authorization server, not for the relying party. Authorization needs to identify the end user and for that only the authentication used.
Once the authorization server authenticates the end user, it sends back access token which can be used to communicate with a protected endpoint. And the access token authorizes the relying party to use the protected service.
Access tokens never say anything about the end user. They are opaque to the RP and can only be consumed by the authorization server. But id token is a JWT with end user details. That's why I said OpenID Connect provides authentication.
How to choose between OAuth2.0 and OpenID Connect ?
There are many facts you need to consider. Which include the question of "does identity provider support protocols?". But, it all boils down to the fact of how you consume tokens.
If your client application simply allows the end user to consume protected endpoints and does not bother about their identity details, you should use OAuth2.0.
But if your client application is concerned about identifying end user and authenticating them(think about client application's other functionalities such as a database call or even a welcome message which require those) then you should use OpenID Connect.
I have implemented an OAuth2 register workflow (in Java) according to rfc6749
I'm using GitLab as OAuth2 Provider.
After the user granted access to my application for his account, I get an OAuth Token (along with refresh token and other stuff), I am able to make API requests on behalf of the user, so this is working fine.
This way I can get the users e-mail adress which I use to create an internal user.
My questions are:
Is it practice to issue a token that is generated by my application for the user (along with the OAuthToken) or should I just use the token that has been issued by the OAauth Provider? (My App also has local auth with bearer tokens). This token will be used for further API - CLIENT communication (stored in Angular2 local storage as bearer)
How to do login only? When a OAuth User accesses my web service, how do I know that this user is a OAuth User and which OAuth Token belongs to him? How can the user login without providing e-mail or password? (The user has no password) I guess I have to redirect him to the OAuth Provider again, but I don't want my user to grant access everytime he logs in.
Answer 1:
Though you can use the token provided by OAuth provider, you SHOULD NOT use it considering the risk that may arise exposing it to the public.
Instead you should securely save the token provided by OAuth provider into the database and use another token for authentication of further api calls. (you could use JWT)
Answer 2:
There are two types of systems
Which always uses OAuth provider for identifying user. (Ex. Tinder)
Which provides both OAuth Login and Traditional login/signup. (Ex. Quora, Instagram)
If you want your application to follow 2nd approach, you should ask the user to create password for the first time when the user logs in using OAuth provider.
This will allow the user to log into your application by both methods, traditional as well as OAuth
To identify users of your application, you should either use HTTP session or issue your own tokens. Do not use tokens generated by the OAuth2 provider - they are meant to be used just by your backend (in role of an OAuth2 client).
To use an external authentication in your application, you probably want to use OpenID Connect, not a bare OAuth2. OpenID Connect extends OAuth2 and it's meant for authentication instead of the rights delegation. Then you use an implicit flow (instead of authentication code grant) with scope=openid, your frontend app (HTML+JavaScript) gets an ID token signed by the OAuth2 provider. After successful signature verification, your backend can trust that the client is the one described in the ID token (in its "sub" field). Then you can either keep using the ID token or generate your own token.
Can someone shed some light on the use case for me. We wave users who will be signing in to third party client applications. Using OAUTH2 framework, the client app will redirect to our site to authenticate. From my undestanding, the Authorization server will return a access token and an id_token (OpenID Connect).
1) If the user is authenticated with us and is redirected to the client application, if they leave the client application and go back into the client application hours later, do they still have go through the whole redirect to our /authorization endpoint to re-authenticate?
2) If the user is authenticated with us and is redirected to the client application, if they leave the client application and go to our site, do they have to login again to authenticate?
Basically, does OpenID Connect over OAUTH2 allow a user to sign in once and then not have to sign in again after subsequent visit to the third party app or our app?
Thanks.
It depends on two things:
a. if the client application maintains a session and that session has not expired yet, the user won't be redirected at all
b. in case the client session timed out, the user will be redirected but if the IDP still has an authentication session running, the user will not have to authenticate and will be sent back immediately to the client app with a new token.
It depends on the IDP session existence/timeout again
Essentially an Identity Provider authenticates users and decides how to do that. It can prompt for credentials but can also create and maintain authentication sessions for the user for (typically) a limited period of time which allows for true Single Sign On (SSO).
Also note that this behaviour does not depend on the exact protocol at hand (OpenID Connect, OAuth or even SAML): it would work the same for any protocol that redirects a user to an Identity Provider in a federated SSO system.
In OpenID Connect, the session at RP typically starts when the RP validates End-User's ID Token. ID token consists of expiration time. So if the user just leaves (not logged out) and the id_token is expired when he access the RP, then the end-user needs to re-authenticate.
If the end-user logged out from the relying party and the OpenID provider supported logout mechanisms such as OIDC session management, OIDC front-channel logout or OIDC back-channel logout, then all RPs sharing the same browser session will be logged out (SLO). Then the end-user needs to login to the OP again to access the RPs.
OIDC doesn't support Resource Owner Password Credentials Grant. Why? Some of my clients are secured devices which could safely maintain credentials... Those credentials could be used to get an access_token. Can I still use OpenID Connect?
It is not explicit in the specification but OpenID Connect supports all OAuth 2.0 flows since it is an extension of OAuth 2.0.
The spec talks about the flows that involve browser redirect as they are more common, more secure and less brittle given that resource owner credentials only supports username and password and is only in the OAuth 2 spec for backwards compatibility. In true SSO systems you'd want to abstract away from the method of authenticating the user at the OP/IDP. Involving a browser is a way to do that.
But your mileage may vary wrt. support in specific OP/AS software and client libraries.
FWIW: you should be looking to obtain an id_token rather than an access_token.
OpenID Connect performs authentication to log in the End-User or to
determine that the End-User is already logged in. OpenID Connect
returns the result of the Authentication performed by the Server to
the Client in a secure manner so that the Client can rely on it.
With implicit and authorization codes grant types flows, it is not possible to issue an ID token if the End-User is not logged in. In this case, the authorization server can confirm to the relying party that End-User is logged in.
But with the resource owner grant type flow, the authorization server cannot confirm the End-User is logged in. You can issue an access token even if the End-User is not logged in.
Yes. I also was finding answer for same question sometimes back. According to the OpenId Connect specification, It is recommended to use authorization code and implicit grant types for OpenId Connect requests. But it is not mentioned that other grant types can not be used. Therefore you can use any other grant types for OpenId Connect authentication request. There is some mail from the openid connect group, which has been discussed on this. Please find it from here. If your OAuth2 Authorization server supports it, I guess that it is fine to use it. As i know, most of the Authorization servers support it, as an example from here