I am confused with access_token and id_token of OIDC, which one should be set to authorization header when making request to a resource owner? Is the id_token only for client to display user information without making request?
I think similar question is answered by ajaybc here - https://stackoverflow.com/a/19443840/4794396.
To say, id_token is required for the authentication of the user. And access_token is mandatory for reaching out to the end-point.
PS: Couldn't leave a comment as I haven't got 50 reputations yet.
Related
Is it possible for /token endpoint to just return id_token and not access_token in case of authorization code flow? I could not find anything mentioned around this in OIDC spec the way I read it. I would appreciate and pointers in documentation around this.
According to section 3.1.3.3 in the spec it says
After receiving and validating a valid and authorized Token Request from the Client, the Authorization Server returns a successful response that includes an ID Token and an Access Token.
So I guess you always gets both, but its up to you to ignore the tokens you don't care about.
I'm researching to use OIDC for SSO (Single Sign On).
I know OIDC flow always return id_token and access_token but I don't know why we need id_token?
As I know id_token used only by client application to get authenticated user information. Client application will decode and verify JWT then extract user information from it.
But because I have access_token, I can use it to get user information from endpoint /userinfo. So I dont't need id_token?
Please help me understand the right way to use id_token.
You are correct that you can get the user details using the access token from the /userinfo endpoint.
The ID-token represents details about the user and more important how the user authenticated (password, 2FA...). The lifetime of the Id-token is often very short (like a few minutes).
Just like how the specification describes it:
The ID Token is a security token that contains Claims about the Authentication of an End-User by an Authorization Server when using a Client, and potentially other requested Claims.
I am implementing openid connect for google and microsoft. Openid provides the id_token which also content the user info. I am still confused. How to use id_token. In oauth2 we are storing the access_token in our db. so we use access_token to get user profile. If I am getting the profile mean user is authenticate and user will login into app. So in id_token case, should I validate the token. If token is validate then user will login. I am really confused. Please help me out. Please provide the flow of authentication.
Read this: http://www.thread-safe.com/2012/02/why-we-need-idtoken-in-openid-connect.html
TL;DR id_token removes the need for that extra round trip you need to make to get userinfo. Instead OIDC presents you with both an id_token which contains all the info you need about your current user and an access_token.
If token is not required for authentication. It is only useful in public clients to get some user attributes aka claims.
I am trying to use the following enpoint for social authentication with auth0.
https://YOUR_NAMESPACE/authorize
The documentation clearly states that given the response_type=token we should recieve an access_token and an id_token in the hash fragment.
https://auth0.com/docs/api/authentication#!#get--authorize_social
But for whatever reason, I only get back the access_token. The login seems to work fine, and authenticate with google, but when redirected to the callback, the id_token is just missing. The access_token, state, and token_type are present at-least.
I've attempted using the /oauth/access_token endpoint to receive the id_token given I already have the access_token, but making that request (I've triple checked I'm doing it correctly) always yields a 401 unauthorized.
Auth0 is clearly a worthwhile product, so I very much doubt its straight up not working. Can anyone point me in the right direction? Googling around has not been helpful so far.
I'm not sure where the docs say that response_type=token would deliver both an access_token and an id_token in the fragment but the OAuth 2.0/OpenID Connect specifications themselves say that token should return just an access_token and instead the token id_token response type would deliver both. I guess that's worth a try. Also make sure that you include the scope openid in the authorization request.
I am facing a custom implementation of OpenId Connect. But (there is always a but) I have some doubts:
I understand the process of obtainning an acces_token an a id_token, except the step when the OP provides an authorization_code to the client. If it is done by a redirect (using the redirect uri)
HTTP/1.1 302 Found
Location: https://client.example.org/cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=af0ifjsldkj
The end-user is able to see that authorization code? It does not expire? Imagine we catch it and we use later (some days later) Is it a security hole? Should the state be expired in the Token Endpoint?
The flow continues and we got at the client the Access_token and the id_token in the client.
How the Access_token should be used on the OP side ? It should be stored in a database? Or be self containing of the information required to validate it ?What would you recommend?
And in the client-side , both tokens should be sent in every request?
And the last doubt, if we have an Access_token the existence of an id_token is for representing authorization and authentication in separated tokens?
Extra doubts:
I know the process to obtain an access token but I have doubts of how the OP ,once generated and sent, it validates the access_token that comes with every request
How the OP knows an access token is valid? As far as I know, the OP should say that an access_token is valid/invalid. There should be some way to check it right? How it gets to know that a token represents a valid authenticated user if it is not stored in DB?
Is it a bad idea to store access_token in a cookie? Because sometimes we call to some webservices and we want to send access_token as parameter. Or there is another workaroundsolution?
How the access token should be stored in the Client , for example, in ASP.NET, in the session?
Thanks very much to all of you, I will give upvote and mark as answer as soon as you give me the explanations.
Thanks!
The end-user is able to see that authorization code?
Yes. Although, even if the authorization code can be seen, the token request requires that the client's secret be sent as well (which the browser does not see)
it does not expires? Imagine we catch it and we use later (some days later) It is a security hole? Should the state be expired in the Token Endpoint?
The spec says that the authorization code should expire. See https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2.
How the Access_token should be used on the OP side ? It should be stored in a database? Or be self containing of the information required to validate it ?What would you recommend?
The access token should be stored on the OP if you want to be able to revoke the tokens. If you don't, the token will be in JWT format (self-contained)...but you should store it if you want to be able to revoke it whether it's a JWT or not.
And in the client-side , both tokens should be sent in every request?
No, just the access token.
And the last doubt, if we have an Access_token the existance of an id_token is for representing authorization and authentication in separeted tokens?
Yes, they are separate tokens for different purposes. Access token is for authorization and Id token is self contained and used to communicate to the client that the user is authenticated.
How the OP knows an access token is valid? As far as i know, the OP should say that an access_token is valid/invalid. There should be some way to check it right? How it gets to know that a token represents a valid authenticated user if it is not stored in DB?
see How to validate an OAuth 2.0 access token for a resource server? about thoughts on how the resource server should validate the access token before letting the request from the client go through.
It´s a bad idea to store access_token in a cookie? because sometimes we call to some webservices and we want to send access_token as parameter. Or there is another workaroundsolution?
I'm assuming you're using the authorization code grant flow (...from your questions). If that's the case, the reason why an authorization code is, first of all, passed back from the OP rather than the access token is so that the access token can stay hidden on the server side--away from the browser itself. With the authorization code grant flow, the access token should stay out of the browser. If you're wanting to send api requests to the resource server directly from the browser, then look into the oauth2 implicit flow (https://www.rfc-editor.org/rfc/rfc6749#section-4.2).
How the access token should be stored in the Client , for example, in ASP.NET, in the session?
In the OpenID Connect flavour of OAuth2, the access token is for offline_access (i.e. outside of an authenticated "session"). The access token could be used during the session of the user but it might be better to store the refresh token in the database so that your client app can request new access tokens whenever it needs to and as long as the refresh token is valid...even when the user's authentication is expired. The access token should be short-lived so storing it in the database is an option but not necessary.