Can I use JWT tokens with struts2, if yes, please guide.
We have an authentication server that provided JWT token and my old struts2 app must validate through it.
Related
I have done a sample application using Sprint Boot, Spring security and JWT and define my custom authentication & authorization filters. While performing basic authentication (passing username & password) I get JWT token in the format of xxxx.yyyy.zzzz where xxxx is header, yyyy is payload and zzzz is signature and each part is encoded using Base64URL encoder. What I do not understand is how JWT is different from OAuth 2.0. In OAuth 2.0, we can pass 2 types of grant_types as either 'username' or 'client credentials' & also needs to pass client id, secret id to get access & refresh tokens.
Please assist to clarify my following doubts:-
1) Is JWT lighter than OAuth 2.0 as it does not contain the refresh token but just access token?
2) Is JWT cannot be used to make a standalone authorization server like we can make a standalone authorization server using #EnableAuthorizationServer annotation when it comes to OAuth 2.0. Is my assumption correct?
3) JWT does not accept client id/secret client but just used as basic authentication to get bearer tokens?
4) Is the format of access token (or bearer) for both OAuth2.0 and JWT are different?
I have seen an example where both OAuth 2.0 and JWT were used. OAuth 2.0 was to make authorization server which returns JWT token only in the end but did not understand why JWT was used if OAuth2.0 can return a token by itself.
Thank you
JWT is a JSON-based token defined in RFC 7519. OAuth 2.0 is an authorization framework defined in RFC 6749. Comparing both is like asking "How Glucose is different from Apple Pie?".
However, it is possible to bring OAuth 2.0 and JWTs together as is defined in RFC 7523 – The JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants. It standardizes, how to use JWTs as bearer tokens within the OAuth 2.0 framework, which enables what I call stateless authentication.
Regarding your questions:
Whether or not you use JWTs as bearer tokens does not influence whether or not you want to hand out refresh tokens.
Not sure whether I get your questions. However, using JWT allows you to do decentral, stateless auth decisions as there is no necessity to store token state centrally. However, nobody prevents you from having a standalone authorization server.
How you want to do authentication has nothing to do with JWT. It is still OAuth 2.0.
In OAuth 2.0 bearer tokens are considered to be opaque tokens – the format does not matter. If you use JWTs as bearer tokens, you need to follow the corresponding RFC.
I am creating a new SPA with a REST API and for the backend I am using Rails with devise_token_auth. I am new to token authentication and while searching I am seeing a lot of libraries for frontend libraries that support JWT but I can't tell if this is compatible with devise_token_auth.
Is JWT the standard for web tokens and is it what devise_token_auth uses?
No, devise_token_auth gem doesn't use JWT.
It authenticates a user by validating the client-id, access-token &
UID and processes the request. All these keys are received during a
successful login.
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 am using the doorkeeper gem with jwt on my rails-api backend and a angularjs frontend (satellizer).
Question 1
Do I need to share JWT sercet key to the frontend (the angularjs app)?
Question 2
How does doorkeeper verify JWT tokens?
Thanks!
Answer. No, you don't have to share JWT secret key with anybody. Only components that need to know what is "inside" JWT token need to have it.
To my understanding, no. You have to do that by yourself in your controllers. Doorkeeper only checks if token as "string" is valid - expired. It treats it as any other token.
Does oauth2RestTemplate or access token providers support validate token request?
Here is the flow:
Mobile/Web-App authenticated from third party Authentication server
and obtains Access-Token.
User tries to access a secured resources, and passed the Access-Token in the request, as expected by the protocol.
Is it possible to check this token against third-party server?
I found a bit similar here in the form of a refresh token.
Is validation request the part of the OAuth2 standard?
Thanks
No, OAuth2 doesn't enforce a specific token format or API for validating tokens. This is something that has to be decided independently between the resource server and the authorization server.
For example, the UAA project, which uses Spring Security OAuth2, uses signed JWT tokens, so the resource server can validate the contents without having to ask the authorization server directly. It also provides a /check_token endpoint, which will decode the token and verify that it has not expired.