I am using spring oauth2 for generating bearer tokens and validating them. I store tokens in database. I would like to know that is there any facility provided by spring oauth2 to cache the token as it is costly to go to db and fetch the token for validation when the servers are hit by 100tps.
I get that this is old but for the benefit of others.
Try not to store tokens anywhere unless you need the facility to revoke them. If you are committed to not storing them, that by default means you are (or should) be using JWT formatted tokens.
Spring, by default, includes user data in the bearer access JWT token that is produced.
Therefore your client / resource server that is a recipient of the JWT token has enough knowledge to automatically create an authentication object and manage access to resources.
Related
I need some lights about convenience of using an autheorizarion server in my project scope.
We're realising and deploying our services into customer environment.
Customer infrastructure already provides an authentication mechanism in order to authenticate users.
This mechanism intercepts all comunications and redirects user to a "login" form.
After that, user is redirected to our service and we've to handle and digest it and respond with an JWT token.
Here is where I'm feeling lost:
I'm thinking about:
using spring-oauth2 in order to request a JWT token to an authorization server, or
using spring-oauth2 in order to auto-generate an JWT token and validate it. I don't know if it's possible.
My question is, since user is already authenticated, have it sense to use an oauth2 authorization server, using client-credentials in order to authentication client against our resource services?
Short question would be, could I use spring-oauth2 librearies in order to generate a JWT without an authorization server?
You technically can do it, but I would discourage you from doing that. Access tokens in a system should be issued centrally, by a dedicated service. Otherwise, it will be hard to maintain the infrastructure. If your services will start to issue JWTs, then they will also have to provide the public keys for others to validate these JWTs. Keys management, access token contents management, and any rules of mapping user information into claims - will now become part of your service and it will unnecessarily complicate its implementation.
If the customer's authentication mechanism issues a JWT, why not use that one for request authorization? If that one is insufficient, I would recommend having an Authorization Server (or a dedicated service), that can perform Token Exchange and exchange the original JWT for a new one.
I am very confused about the difference between oauth2 tokens and json web tokens.
I have searched about these technologies and the result is ;
Open Id is a protocol and It uses JSON Web tokens to ensure the requests are coming from a trusted user.
A Json web token contains a few user information ( claims ) as encrypted with a private key of sts.
Oauth2 is a framework and we can manage the login operations between our users , clients and resources and third-party applications.
Identity Framework 4 is an Open Id connect implementations .net MVC library. The library has written with oauth2 specs and it implements Open Id.
This is the point I didn't understand. The Oauth2 framework already has its token implementation.
Where is the place of JSON web tokens in this scenario?
For example, we have a simple web application and a server which implements identity server 4.
When a user requested a page from web application user will be redirected to our identity server to login operation.
After successful login Identity server adds a cookie to our response and these cookıe contains a token.
We wıll use that token when requests the other secure resources .
These steps are clear for me. Where is the Jason Web token in this schenio ?
How can I use JSON web tokens in my client app?
Where can I reach my user claims?
The reason for JWT is given in the specs of OAuth2
Since OAuth 2.0 does not define a protocol for the resource server to
learn meta-information about a token that it has received from an
authorization server, several different approaches have been
developed to bridge this gap. These include using structured token
formats such as JWT [RFC7519] or proprietary inter-service
communication mechanisms (such as shared databases and protected
enterprise service buses) that convey token information.
Being an open-standard JWT has been largely adopted in security-related technology and protocols. It defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed
Let's explain some concepts of this definition further.
Compact: Because of their smaller size, JWTs can be sent through a URL, POST parameter, or inside an HTTP header. Additionally, the smaller size means transmission is fast.
Self-contained: The payload contains all the required information about the user, avoiding the need to query the database more than once.
There are a lot of sites explaining these things as well as numerous technology providers.
https://jwt.io/introduction/ for providing tutorials and free e-book
https://oauth.net/2/ for in-depth stuff
https://openid.net/connect/ for the new kid on the block
To answer your IdentityServer related questions. Authentication & authorization related information are usually encoded
access token
identity token
The application-specific information/payload in these tokens is encoded using JWT. JWT is mostly transparent to application developers if good libraries are provided - as is the case for IdentityServer. You will find answers to your questions in the excellent documentation for IdentityServer. How to extract user claims is covered as well. The project provides numerous client examples that cover typical AuthX setups out there. It takes time and commitment to get through it.
JSON Web Token (JWT) (RFC 7519) itself is independent of OAuth 2.0 and OpenID Connect. You can use JWT wherever you like.
OAuth 2.0 is a specification as to how to request and issue access tokens. The specification does not say anything about how access tokens should be represented. Therefore, access tokens may be random strings or may be JWTs. Some authorization server implementations generate random strings and issue them as access tokens, and other implementations generate JWTs and issue them as access tokens. See “7. Access Token” in “Full-Scratch Implementor of OAuth and OpenID Connect Talks About Findings” for further discussion.
OpenID Connect is a specification as to how to request and issue ID tokens. The specification says an ID token is a kind of JWT. In addition, JWT is used in other places in the specification. Responses from UserInfo Endpoint are either plain JSON or JWT. Request Objects are JWT.
In normal cases, a server which supports OpenID Connect can issue both ID tokens (which are JWTs) and access tokens (which are either random strings or JWTs). This may be making you confused. Reading the following articles may be of help.
Diagrams of All The OpenID Connect Flows
Diagrams And Movies Of All The OAuth 2.0 Flows
I need to realize SSO system using Oauth2.
I understand steps in oauth2, but I don't know what's the Specific algorithm in generating an authorize code or an access_token,maybe Hash or something.And I can't find it on the internet
OAuth 2 specs:
Access tokens can have different formats, structures, and methods of
utilization (e.g., cryptographic properties) based on the resource
server security requirements.
The format of the tokens (and authorization codes) are not defined by the specs, so there is no specific algorithm.
The specs do require:
The authorization server MUST ensure that access tokens cannot be
generated, modified, or guessed to produce valid access tokens by
unauthorized parties.
So, for instance a random UUID makes a fine token. You could also consider JWT tokens.
OAuth2 spec doesn't specify any algorithm or way to generate token value. You can use whatever algorithm, even serial number starts from 1, to generate those token values. You can use more complicated random number generation, encryption, crypto algorithm. Most of them are pretty quick to generate key value, but you need to check how fast current authentication server can generate a key and if it meets your service's requirement.
For example, for token generation in Spring Security, DefaultTokenServices generates access token and refresh token using random UUID.
Unless you want to implement your own Oauth generator, you can use existing providers like WSO2 API Manager for supporting your system. It is well documented and has many REST APIs for this.
access_token contains the claims. So do authentication of user/client and other validations as mentioned in oauth2 spec. Then if you consider JWT for access_token format then you can use jose4j api for access_token creation which supports JWE and JWS as well.
OAuth2 does not define a specific method to generate or protect tokens (authorization code, access/refresh token).
You can implement any strong symmetric cryptographic algorithm, so that you can protect or encrypt the token you are sending.
If you don't want to check token against database you should have this strong encryption.
If it is fine to check token against database you can use a key-value pair, so that you provide key to user and value is stored only in database.
From what I can tell, the OAuth 2.0 specification is extremely vague in terms of what form an access token should take:
The token may denote an identifier used to retrieve the authorization
information or may self-contain the authorization information in a verifiable manner (i.e., a token string consisting of some data and a signature). Additional authentication credentials, which are beyond the scope of this specification, may be required in order for the client to use a token.
The access token provides an abstraction layer, replacing different authorization constructs (e.g., username and password) with a single token understood by the resource server. This abstraction enables issuing access tokens more restrictive than the authorization grant used to obtain them, as well as removing the resource server's need to understand a wide range of authentication methods.
Access tokens can have different formats, structures, and methods of utilization (e.g., cryptographic properties) based on the resource server security requirements. Access token attributes and the methods used to access protected resources are beyond the scope of this specification and are defined by companion specifications such as RFC6750.
(emphasis added)
The linked RFC6750 doesn't offer much further specificity. There is an example HTTP response body that shows:
{
"access_token":"mF_9.B5f-4.1JqM",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}
This seems to indicate that the access_token can be opaque ASCII text such as an encoded JSON Web Token (JWT)
From my perspective, it seems like JWT-as-access_token has some desirable properties:
It's a known specification, with fairly wide adoption and client libraries available in many languages.
It allows for easy signing and verification using vetted cryptographic libraries.
Because it can be decoded to JSON, it would allow us to include metadata and information about the token within the token itself.
My questions are: First, is it permissible for the access token to be a JWT? Second, if it is permissible according to the spec, are there any additional considerations that would make using a JWT as an access token a bad idea?
A1: Using a JWT as an access token is certainly permissible by spec exactly because the spec does not restrict its format.
A2: The idea behind using a JWT as an access token is that it can then be self-contained so that the target can verify the access token and use the associated content without having to go back to the Authorization Server. That is a great property but makes revocation harder. So if your system requires a capability for immediate revocation of access, a JWT is probably not the right choice for an access token (though you can get pretty far by reducing the lifetime of the JWT).
As long as the Authorization Server and the Resource Server agree on what the access token means, it doesn't matter what their content is. So the only reason you could have a problem would be if you were using different libraries or frameworks when implementing those two servers.
Currently the OAuth Working Group is working on a JWT profile for OAuth 2.0 access tokens: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
I am learning oAuth2 for the first time. I am going to use it to provide authentication for some simple web services using a two-legged approach.
According to what I have read, the flow should go like this: the web service client supplies some kind of credential to the oAuth server (I'm thinking of using JWT). If the credentials are valid, the oAuth server returns an access token. The web service client then supplies the access token when attempting to use the web service end point.
Here is my question, why not just supply the JWT when making a request to the end point? Why is oAuth's flow conceived this way. Why not just supply to JTW to the end point and use that for authentication? What is the advantage of having the extra step of getting an access token?
Thanks!
You can certainly supply the JWT directly to the web service. The questions is how do you generate it in a way that the service trusts.
A JWT is and access_token, but not all access_tokens are JWTs.
Your client can issue a JWT, sign it with a key (or a cert) and then send it to the API. The advantage of having a 3rd party (an Issuer) is that you can separate authentication from issuing tokens. Clients can authenticate in multiple ways (e.g. usr/pwd, certs, keys, whatever) and then use the JWT to call your API.
The additional abstraction gives you more flexibility and management scalability. For example: if you have 1 consumer of your API, then you are probably ok with a single credential (or JWT, or whatever). If you plan your APIs to be consumed by many clients, then handing that responsibility to a specialized component (e.g. the the issuer) makes more sense.
OAuth BTW, was designed for a specific use case: delegate access to an API to another system on your behalf. You grant access to system-A to access resources on system-B on your behalf with a permission scope.