OAuth2RestTemplate uses OAuth2ClientContext for saving the access token. But I am unable to understand how OAuth2ClientContext is persisting access tokens between subsequent request.
NOTE:- I am using client_credential grant type and my application is stateless.
The OAuth2ClientContext-Bean is instanciated in scope "Session", so it is individual for each user-session.
See: http://docs.spring.io/spring/docs/3.0.0.M3/reference/html/ch04s04.html#beans-factory-scopes-session
Related
We have a Web API secured with IdentityServer4 using local API authentication. We are currently using both Reference Tokens and Refresh Tokens. Since we have the ability to revoke a reference token at any time is it even necessary for us to use refresh tokens? Couldn't we just set a long expiry for the reference token? Is there any security implications to this approach?
From the documentation:
When using reference tokens - IdentityServer will store the contents
of the token in a data store and will only issue a unique identifier
for this token back to the client. The API receiving this reference
must then open a back-channel communication to IdentityServer to
validate the token.
In other words, the client doesn't have to provide an access token to the api, only pass the reference.
This is a big difference between the JWT token and the reference token. The client sends the API the JWT token that has to be trusted by the API without consulting the provider, while the reference token forces the API to contact the provider, not having to rely on the client.
From the Refresh Tokens documentation:
Since access tokens have finite lifetimes, refresh tokens allow
requesting new access tokens without user interaction.
The question now is, can a reference token expire? Not from itself, as it contains no logic, unlike the JWT token. But there may be a server side setting that triggers some kind of expiration, or actually cause the reference to be revoked.
Either way, there is no use for a refresh token in this scenario. As you can't refresh the reference token. The reference token either exists or not (is invalid or was revoked).
In OAuth2 protocol, Client (RP in terms of OIDC) application obtains an access token, which enables it to use different services (Resource server role) on behalf of a Resource Owner.
On the other hand, in the OpenID Connect protocol, Client obtains 2 tokens (access and id token). Now this Client can use the access token to fetch user claims from the UserInfo endpoint.
Does OP (Authorization server) play role of a Resource Server here (in terms of OAuth2), and Client fetches user data on behalf of a user?
How is ID token used by the Client? Does Client pass this ID token to the Resource Owner's user agent (Browser) and then, user agent stores this token to enable SSO (cookie)?
Does Client (e.g. different one than the one that obtained the ID token) has to verify the token every time user accesses it (call OP to verify it), or Client does this only first time it gets accessed by this token and then creates security context which enables it to eliminate this request for verification at OP every time? In this case, how could this security context be implemented?
What is the access token used for, except for fetching user claims and why is it sent along with ID token, when Client could use ID token to access UserInfo endoint?
First of all you must understand the purpose of tokens. Access token is a token that is good enough to access a protected resource on behalf of the end user. It is defined by OAuth 2.0 authorization framework. Now having an access token does not authenticate the end user. it simply authorize the client application to access a resource. OpenID Connect introduce the ID Token. Now this token is to be consumed by your client application. Protocol define how this to be done and if valid, your client application can authenticate the end user.
Q: Does OP (Authorization server) play role of a Resource Server here (in terms of OAuth2), and Client fetches user data on behalf of a user?
Partially correct. According to the protocol document, userinfo endpoint acts as OAuth 2.0 protected resource.
The UserInfo Endpoint is an OAuth 2.0 Protected Resource that returns Claims about the authenticated End-User. To obtain the requested Claims about the End-User, the Client makes a request to the UserInfo Endpoint using an Access Token obtained through OpenID Connect Authentication.
Q: How is ID token used by the Client? Does Client pass this ID token to the Resource Owner's user agent (Browser) and then, user agent stores this token to enable SSO (cookie)?
As mentioned previously client must validate the id token and based on that it can authenticate the end user. ID token is not connected with SSO.
Q:Does Client (e.g. different one than the one that obtained the ID token) has to verify the token every time user accesses it (call OP to verify it), or Client does this only first time it gets accessed by this token and then creates security context which enables it to eliminate this request for verification at OP every time? In this case, how could this security context be implemented?
If you are using ID token to be consumed from a protected endpoint, then token receiving party should validate it before accepting it. One may choose to create a session after a proper token validation (session must not extend the life time of the token).
Q: What is the access token used for, except for fetching user claims and why is it sent along with access token, when Client could use ID token to access UserInfo endoint?
Access token is the token your should use to access OAuth 2.0 protected resources. Once the endpoint received it, endpoint can validate the access token against token introspection endpoint exposed by the authorization server (Protocol definition of introspection). And with Openid Connect, defining of userinfo endpoint let any party with valid id token to consume it.
I don't see how you can be confused about that if you've read the RFCs.
You want to think of identity as a "resource" service? fine, but the authentication for this service is different than for RPs, so what's your point?
The Client exists in the User Agent (we're talking about SPAs, right?). If the ID token is in the Client, then it's in the UA (the reverse is not true). If you're thinking of server-side clients, then there is no need to forward the ID token to the UA, unless you want the UA to pass it on to another Client (e.g. for SSO). There are SSO schemes that use the ID token for convenience, but that's not the stated purpose of the ID token.
The whole point of JWS is that you don't need to call the OP to verify a token. You just verify the signature. That may be done by any Client, whether they're the original recipient of a token, or they get it later. Furthermore, the ID token is not meant to authenticate the user. Using it for SSO requires some other form of security, such as storing a related secret in an HTTP-only cookie that will not be seen by the Client. Anyway, even if you use the ID token for SSO, then the ID token is sent only in the login request. After that, the Client will get its own access token for authentication and will not use the ID token again.
The access token is typically short-lived (which means the Client has to contact the OP regularly, which allows the OP a chance to revoke access). The access token is sent with every authenticated request, so it should be small (i.e. not contain user information that is not useful for authentication).
I am working on an ASP.NET MVC client application. User is authenticated and authorized via another API application which returns token.
Currently, after client app recieves token from API, it saves token in session and sets form authentication cookie for app authorization.
FormsAuthentication.SetAuthCookie(TokenViewModel.Username, rememberMe);
HttpContext.Current.Session["AuthenticationToken"] = TokenViewModel;
Should i keep using form authentication, or just save token in session? or user OWIN here to authorize user.
Client app uses [Authorize] attribute.
If you are using [Authorize] attribute, by default the API will check for the access token in the Authorization header of the HTTP request, not in the cookie.
If you want to use the cookie, then go for forms authentication or customize the Authorize attribute to check for the token inside the cookie.
So, it's better to keep the token in session and at the same time manage it's lifetime(token expiry) explicitly. Apart from that, you can use refresh tokens to get new access token after or before the current one expires.
I am trying to implement OpenId Connect for SSO in one of my projects. However, I am a bit struggling with the case where I would like to validate OpenId JWT token on Resource Server side to make it stateless. If user tries to logout, authorization Server will know about the user logout (Accordingly OpenId Connect Session Management spec). But how should Authorization Server tell Resource Server that the user's token is not valid anymore? It is a case when user after log out out goes to Resource Server with his OpenId token and gets access. That is weird and I could not find any solution across Internet. Please help me to organize stateless security with central logout.
You can use Token Introspection endpoint to determine whether the access token passed is valid or not. The resource server can make a call to OP's introspection endpoint to validate the token before giving access to the resource. In order to effectively validate the token, the resource server should :
Be a registered client with OP and have Same / similar Scope as SPA app (Implicit flow app) to validate the scopes passed to it and
Have access to Introspection endpoint
The are more details in the above linked Spec for further understanding.
P.S. The answer that I wrote earlier has some other relevant references.
you can use jwt bearer flow, where you can pass ID token/Assertion token to OP in order to generate access token.
I am new to OAUTH and trying out understanding the spec. So as per the spec protocol flow, I understand that Client A, can get Authorization code and then Access Token for a protected resource.
Now if Access Token has been obtained, Services e.g Linked in expects the Access token to be part of URL Query, See their interface document.
So now if Client A has shared access token with Client B, or e.g anyone intercepts the request, and gets the access token, then he too can start accessing all details that Client A can access. Is this understanding correct? If yes, then how can we protect such kind of Access token sharing/misuse?
There are multiple ways to pass an access token to endpoints of protected resources. For example, as a query parameter like:
access_token={Your-Access-Token}
Another example is Bearer Token Usage (RFC 6750) in which an access token is embedded in Authorization header like:
Authorization: Bearer {Your-Access-Token}
How to pass an access token is defined by each service.
Access tokens must be kept secret. If Client B obtains an access token issued to Client A, Client B can behave as if it were Client A. Yes, there are risks of access token leakage, so access tokens have limited lifetime, and it is a reason that most services have a page to enable users to revoke access tokens.