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 client_credentials grant type in my spring boot application. In client_credentials grant_type the client makes a request to the token endpoint. If the access token request is valid and authorized, the authorization server issues an access token.
localhost:8181/OUTPOST/oauth/token?grant_type=client_credentials&client_id=myClientId&client_secret=secret
The problem is my client is a javascript application. Client application wont be able to securely store the client credentials, so there is no point is having client_secret.
Implicit, password and Authorization code needs user details for generating token. But i dont have any user, i just need to validate my client application.
Which grant_type should i use to support my requirement?
The implicit OAuth2 flow is wat you are looking for. Details from the OAuth2 spec: https://www.rfc-editor.org/rfc/rfc6749#section-1.3.2
I don't think what you are asking is really valid. It is not possible to authenticate a JavaScript client securely via OAuth2 without user credentials. This would mean that everyone that can access the JavaScript app would be authenticated.
If you want to restrict access to this app without user credentials, it might be better to add network level policies instead, like IP range whitelisting.
As the JWT token is self-contained, it can be validated locally in the resource server and the resource does not need to send the token to the IdentityServer IntroSpection Endpoint for validation.
I check the implementation of the IdentityServer4.AccessTokenValidation, it validate the JWT token locally if the IdentityServerAuthenticationOptions is set to support JWT. The only way to use the IntroSpection endpoint for the JWT token is setting the IdentityServerAuthenticationOptions to support reference only.
Is there any special case that need to send the JWT access token to the IntroSpection Endpoint?
For the resource server that does not have the cryptographic abilities locally, should it have got the reference token, instead of the JWT token?
JWTs are typically validated locally on the resource server.
It's a technical detail that IdentityServer can also validate JWTs at the introspection endpoint. That could be used e.g. when the resource server does not have an appropriate JWT library (and you don't want to store reference tokens on the IS side).
As per my knowledge, introspection endpoint can be used either independently or with JWT.
These are the two possible scenarios for authentication:
Only JWT: I only use JWT for authentication.
Both JWT and introspection endpoint: Here I use JWT for providing core information (like issuer info) and the introspection endpoint for providing more fine tuned information which needs an additional level of security (like client info, scopes info etc).
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.