If you request a token from the server (with the same credentials and within the lifespan of an old token) should it either:
return a fresh token every time
return the same token with a shorter lifespan
something else / depends on
Is it depending on whether you use a refresh token?
Can you please reference the OAuth 2 RFC in your answer ?
The OAuth 2.0 Authorization Framework is a framework that allow a Resource Owner to CONSENT to allow DELEGATION of their permissions to access a Resource Server to another party (OAuth Client).
The Authorization Request is performed by the OAuth Client and is fulfilled by the Authorization Server only after obtaining CONSENT from the Resource Owner by the Authorization Response (which includes a Access Token).
The Access Token is a Bearer Token with a limited lifetime.
The refresh Token, if used, by the client to requests a new access token by authenticating with the authorization server and presenting the refresh token. The client authentication requirements are based on the client type and on the authorization server policies.
The "same" Access Token is never returned or reused by the Authorization Server.
Reading and following the Security Considerations with any Authentication or Authorization Protocols is a must. Most breaches are caused by implementation errors rather than protocol errors.
You should Tell us what you have tried and show logs or results and Read:
https://stackoverflow.com/help/how-to-ask
I am using Forgerock as my identity provider and am looking for something in their rest api where i can provide an access token in the form of a Authorisation Bearer Token and get the corresponding JWT token to use as a Authorisation Bearer Token in a subsequent rest api call.
Can someone help me with what endpoint I can call in Forgerock to do this? I've had a look at the userinfo endpoint, that seems to return what is in the id_token in json format, but I want the actual id_token. A "token exchange".
thanks
There is no endpoint defined by specifications to obtain and ID token for an access token. Specificaitons define about token intrsopection endpoint (RFC7662) and user info endpoint (which you have already figured out).
Other than these, best option is to obtain ID Token from token response itself. For this you need to follow OpenID Connect request format, which include scope value openid. For this, you will require end use consent (most of the time) which allows authorization server to share their claims through id token.
Google Doc says that you can specify response_type for gapi?.auth.authorize
You can use it to get id_token
I'm building a system with OIDC and OAuth 2.0 (using Auth0), and I'm unsure how to properly use the id_token and access_token. Or rather, I'm confused about which roles to assign to the various services in my setup.
I have a fully static frontend-application (single-page app, HTML + JS, no backend) that ensures that the user is authenticated using the implicit flow against Auth0. The frontend-application then fetches data from an API that I am also building.
Now, which is right?
The frontend SPA is the OAuth client application
My API service is an OAuth resource server
...or:
The frontend and my API service are both the client application
If both my frontend and backend API can be considered to be the client, I see no real harm in using the id_token as the bearer token on requests from my frontend to my backend - this is appealing because then I can simply verify the signed token on the backend, and I have all the information about the user that I need. However, if my API is considered a resource server, I should probably use the access_token, but then I have to connect to Auth0's servers on every API request to both verify the token, and get basic user info, won't I?
I've read this which seems to suggest that the access_token is the only valid token for use with my API. But like I said, I'm not sure about the roles of the individual services. And using the id_token is tempting, because it requires no network connections on the backend, and contains information I need to extract the right data.
What is the right way to go about this?
I like this Medium post about the difference, all cred to this author.
https://medium.com/#nilasini/id-token-vs-access-token-17e7dd622084
If you are using Azure AD B2C like I am you can read more here:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/openid-connect
ID Token
You will get id token if you are using scope as openid. Id token is specific to openid scope. With openid scope you can get both id token and access token.
The primary extension that OpenID Connect makes to OAuth 2.0 to enable End-Users to be Authenticated is the ID Token data structure. The ID Token is a security token that contains Claims(claims are name/value pairs that contain information about a user) about the Authentication of an End-User by an Authorization Server when using a Client, and potentially other requested Claims. The ID Token is represented as a JSON Web Token (JWT)
{
"iss": "https://server.example.com",
"sub": "24400320",
"aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"auth_time": 1311280969,
"acr": "urn:mace:incommon:iap:silver"
}
The above is default JWT claims, in addition to that, if you requested claims from service provider then you will get those as well.
An id_token is a JWT, per the OIDC Specification. This means that:
identity information about the user is encoded right into the token
and
the token can be definitively verified to prove that it hasn't been
tampered with.
There's a set of rules in the specification for validating an id_token. Among the claims encoded in the id_token is an expiration (exp), which must be honored as part of the validation process. Additionally, the signature section of JWT is used in concert with a key to validate that the entire JWT has not been tampered with in any way.
Access Tokens
Access tokens are used as bearer tokens. A bearer token means that the bearer (who hold the access token) can access authorized resources without further identification. Because of this, it's important that bearer tokens are protected. If I can somehow get ahold of and "bear" your access token, I can pretend as you.
These tokens usually have a short lifespan (dictated by its expiration) for improved security. That is, when the access token expires, the user must authenticate again to get a new access token limiting the exposure of the fact that it's a bearer token.
Although not mandated by the OIDC spec, Okta uses JWTs for access tokens as (among other things) the expiration is built right into the token.
OIDC specifies a /userinfo endpoint that returns identity information and must be protected. Presenting the access token makes the endpoint accessible.
http://openid.net/specs/openid-connect-core-1_0.html
https://connect2id.com/learn/openid-connect#cool-id-token-uses
https://developer.okta.com/blog/2017/07/25/oidc-primer-part-1
Your frontent is your OAuth client application, once it stores the token it can take actions on the OAuth flow. And your API service is resource server, because it accepts the access_token issued by your identity server.
Also I would say that your id_token stands for the identification of the logged user and may contain sensitive data for your app. The access_token is standing as your credential to access a resource.
At the end you will use an access_token to request a resource, and then if you need specific data from the logged in user (resource owner), you may request the ID token from the token endpoint.
In my opinion, the first approach is correct. Your SPA is the client application and your APIs are resource servers.
I would suggest you limit the use of id_token till your SPA only. You can use the basic information present in the id token (like username and email) to display user information within your UI. If you can generate access tokens as JWTs too then your API can validate the access tokens without going to the Identity provider. You can include roles (or similar) in your access token to get authorization information in your access token.
I was also wondering if I need to talk to the IdP on every request if I'm using the tokens received from the IdP. I ended up with the following setup:
Only the backend talks to the IdP, the frontend does not.
Upon the IdP callback the backend issues a JWT for the frontend.
User session and frontend-backend communication is managed entirely by my app using the JWT token.
Check this article: OAuth2 in NestJS for Social Login (Google, Facebook, Twitter, etc)
and this repo: https://github.com/thisismydesign/nestjs-starter
and this question: OAuth2 flow in full-stack NestJS application
The id_token is an cryptographically encoded token for authentication. The OP (the auth provider) is the one that generates it and the RP (relying party or the resource) will eventually re-present the token to the OP to counter validate when handed over by the client. In short the id_token is tied to authn workflow.
The access_token enables resource access. It does subsume the userinfo i.e., the id_token or any other principal on whose behalf the access is being requested. So this token includes both user claims plus claims to groups that are authorized. In short the access_token is tied to your authz workflow.
Is it possible to exchange an OAuth2 access token (or OpenID Connect id_token) for a WS-* SAML token?
Here is our specific scenario that we would like to accomplish:
A user has been authenticated using an OpenID Connect endpoint and issued an id_token.
The same user has been authorized using an OAuth 2 endpoint and issued an access token.
A single-page application (SPA) requests data from a secured ASP.NET Web API and it sends the id_token and access token.
Here's the question/tricky part: We would like the ASP.NET Web API to fetch data from a WCF service that is secured using WS-*, so the WCF service requires a signed SAML token.
Is it possible to exchange the OpenID Connect id_token and/or the OAuth 2 access token for a SAML token that conforms to WS-* specifications?
We would like to use ADFS on Windows Server 2016, but we're also open to other secure token services (STS), such as Azure ADFS, etc.
It seems that you could implement access token exchange in your OAuth server as there is nothing in the spec strictly forbidding it.
OAuth doesn't make any explicit specifications for what shape your access token or refresh tokens are in. So you could use WS-* or whatever suits your client/RP needs.
You could use any of these types of tokens:
WS-Security tokens, especially SAML tokens
JWT tokens
Custom tokens
The id_token itself MUST be a JWT, however.
The OpenID Connect Spec OAuth 2.0 Multiple Response Type Encoding Practices states that multiple response_type can be combined, e.g. response_type="code token". Now I'm wondering what it's good for to request an authorization code and the token. Isn't the auth code superfluous if you have the token already?
OAuth 2.0 is a protocol framework on top of which other protocols can be built and OpenID Connect is an example of such a protocol.
Especially for OpenID Connect it makes sense to use combined response types because there are 2 tokens in play: the access_token and the id_token. Using "response_type" the client can request how each of the tokens should be delivered.
In the example that that you give, the access_token will be delivered through the front channel as part of the authentication response but the id_token will be delivered when exchanging the "code" for an id_token at the token endpoint in a backchannel call.
A reason for doing this may be that the id_token, which is a signed JWT, does not have to be verified locally when obtained from a proper TLS protected token endpoint, so the client code can be simple. The access_token is opaque to the client anyhow and does not benefit from that.
I've never seen this used in practice. Yes, having the token already kind of diminishes the value of using the code flow.