According to this and this there are two ways to validate the JWT token:
Using RemoteTokenServices which basically calls /check_token endpoint of oauth server, retrieves the whole token and compares it
Expose public key at oauth server and verify the JWT's signature at resource server
At the beginning I tried the first way but since I use custom token converter which hits the database every time token being generated, I decided to switch to signature verification at resource side - didn't want to get an additional database call per every client request.
After some investigation I realized that ResourceServerTokenServices (interface describes token retrieval, conversion and generation a valid OAuth2Authentication object) has only two default implementations: DefaultTokenServices which is primary used in case of oauth and resource servers are parts of the same application and RemoteTokenServices which was described in first approach.
So the main question is whether spring-oauth2 really hasn't default implementation of JWT signature verification or I just couldn't find one?
You do not need a JWT specific ResourceServerTokenServices, so the DefaultTokenServices should do fine. Most of the implementation specific details are sent to the store, so as long as you have a JwtTokenStore configured correctly there should be no issue.
Here :
The Resource Server also needs to be able to decode the tokens so the JwtTokenStore has a dependency on a JwtAccessTokenConverter, and the same implementation is needed by both the Authorization Server and the Resource Server. The tokens are signed by default, and the Resource Server also has to be able to verify the signature, so it either needs the same symmetric (signing) key as the Authorization Server (shared secret, or symmetric key), or it needs the public key (verifier key) that matches the private key (signing key) in the Authorization Server (public-private or asymmetric key). The public key (if available) is exposed by the Authorization Server on the /oauth/token_key endpoint
You can extend JwtAccessTokenConverter to access once the Authorization Server for the exposed public key.
Related
I’m using below java library to validate the JWT token. Creating the Bean to cache the Public key. but I realized (based on Time taken to validate JWT token) that the public key will be cached only when we call the decode function from the AccessTokenVerifier class. this is expensive since we are running the springboot application in multiple pods and this decode method can be called only once we have the token.
which means if we have our application running in ‘n’ pods, for n number of business api calls OKTA internally call the public key endpoint to cache the public key.
Is there any way while the application starting time itself we can cache the public key ?
If you know your authZ server, you can manually request the key from it (please see the okta guide, as it's published in authZ server metadata. Then you can use that key however you want. Not sure if your JWT verification library allows to provide the key manually during its initialization
I want to setup secure interaction between my server and clients and I would like to avoid inventing square wheel.
There is a "REST-Server" in SpringBoot
Service has many "REST-clients" in Java installed somewhere. I don't control it.
"REST-Server" generates public/private key pair for every(!) client and shares pub key with client
every "REST-client" generates it's own public/private key pair and shares public key with "REST-Server". Client shares it's public key along with unique id.
"REST-clients" poll ""REST-server" from time to time
"REST-client" sends request in from:
clientId (helps "REST-Server" to locate right client pub key to decrypt message)
payload encoded with "REST-Server" public key assigned for a given client
original message SHA so "REST-Server" can verify if payload was decrypted correctly
client signature created with client's private key, so server can verify if message comes from authorised client
"REST-server"
locates private key associated with a client by "uniqieId"
decrypts and verifies it with SHA
verifies sender with client signature and known client's pubic key
"REST-server" sends response in form
payload encoded with "Client"'s public key
original message SHA so "client" can verify if payload was decrypted correctly
"REST-client" decrypts response using own private key.
Is there any library / spingboot extension that can do most parts of it?
I would focus more on the client angle than the server one:
Some clients can keep a secret (back end / confidential clients)
Some clients cannot (web / mobile UIs - public clients)
If a client API credential is compromised then you may have a permanent security breach
This feels like a problem that OAuth 2.x solves:
Supports both type of client
Apps work with tokens and never use API credentials directly
Even if a token is stolen it expires shortly after
Threat models are reviewed by experts
In Java I would use a respected OAuth library such as NimbusDS.
Im looking to create an angular application which login against a new authentication server created in springboot and return a jwt.
The idea is to create the application to be able to generate and sign the jwt token with a private key based on the user/password provided in the screen, the authentication server will validate the login information in database and generate the jwt token.
After that, a request will be sent to another microservice and in here I need to be able to validate the token, but this microservice wont be connected to the authentication service or database in any way, it will just validate the integrity of the token using a public key.
Im looking everywhere and I dont find the clue to be able to validate the token, I found this piece of code but for some reason when I execute the rest API exposed this code is not executed:
#Bean
public JwtAccessTokenConverter accessTokenConverter() {
JwtAccessTokenConverter converter = new JwtAccessTokenConverter();
Resource resource = new ClassPathResource("public.txt");
String publicKey = null;
try {
publicKey = IOUtils.toString(resource.getInputStream(), Charset.defaultCharset());
} catch (final IOException e) {
throw new RuntimeException(e);
}
converter.setVerifierKey(publicKey);
return converter;
}
Does what im trying to do makes any sense?
Thanks
Regards
Your auth server will will need to be the single issuer of JWTs to your microservices. So, when a user logs in and successfully authenticates, your auth server will issue a JWT signed with a private key (signing MUST be asymmetric - RS256 is one example) you keep on the auth server only; do not give this private key to other microservices that you wish to validate JWTs inside of. What you can do is derive a public key based on the private key you sign your tokens with and publish that to an endpoint on your auth server that requires no authentication - the public key will be represented in the form of a JWK (see link to spec). Google does something similar here. Then, in each of your microservices, you will need to devise a way to make a GET request to the public key endpoint on your auth server every X minutes and cache the public key in each microservice.
Then whenever a request comes into one of your microservices, you grab the JWT, check its validity, and grant access/authorization if the token is valid. The beauty of using a private/public key pair and asymmetric key signing is that you can validate a token based on the public key alone, but not sign it. So as long as each service has the public key from your /cert endpoint, they can validate a token without ever needing to talk to the auth server or knowing the private key.
This will require a little more work up front, but will yield you massive amount of ease, flexibility, and peace of mind in the future knowing only one source knows your private key.
I suggest using this library to do JWT validation.
The overall architecture will end up looking something like this:
I am implementing an app that connects to an OAuth2 server and it gets back a Json Web Token (JWT). I am passing the token along and I want to independently validate that the token came from the issuing source.
I can do this, no problem, with the public key from the issuing source. I have it available to me for now. Everything works.
But what if the OAuth server changes the signing key? How does the validating app get the new key? Is there a "best practices" convention for sharing the public key from an OAuth2 server? Do we just expose it from an endpoint on the auth server?
There's no solution that is standardized as part of the OAuth 2.0 protocol suite (today).
It was considered to be a single-domain problem that would be solved in various ways that were considered to be out of scope for the core OAuth specifications (much like the API between Resource Server and Authorization Server is/was), and much like any PKI based mechanism in general works today.
But OpenID Connect is a cross-domain SSO protocol that was built on top of OAuth 2.0, which also defined a more standardized option of dealing with key distribution in the form of JWKs URIs as part of the Discover, see the jwks_uri entry at:
REQUIRED. URL of the OP's JSON Web Key Set [JWK] document. This
contains the signing key(s) the RP uses to validate signatures from
the OP. The JWK Set MAY also contain the Server's encryption key(s),
which are used by RPs to encrypt requests to the Server. When both
signing and encryption keys are made available, a use (Key Use)
parameter value is REQUIRED for all keys in the referenced JWK Set to
indicate each key's intended usage. Although some algorithms allow the
same key to be used for both signatures and encryption, doing so is
NOT RECOMMENDED, as it is less secure. The JWK x5c parameter MAY be
used to provide X.509 representations of keys provided. When used, the
bare key values MUST still be present and MUST match those in the
certificate.
This would expose the key material over HTTPs protected channel, effectively leveraging the SSL CA for publishing and rollover of JWT signing key material.
At some point the jwks_uri definition may be part of the standardized OAuth 2.0 protocol extensions as well, but for now you'd have to rely on a custom agreement between Client and Authorization Server to do so. That may not be too hard to implement yourself though.
You may get lucky if your Authorization Server happens to be an OpenID Connect provider as well and uses the same key material for signing ID tokens as well as JWT access tokens.
Updated 4/22/2019: the Authorization Server metadata document is now also standardized it its own OAuth 2.0 extension OAuth 2.0 Authorization Server Metadata RFC8414
I want to use OAuth JWT token for authorization. By some reasons (osgi container) I can't use spring-oauth-security.
In the readme of spring-oauth-security I have found a quote:
The JSON Web Token (JWT) version of the store encodes all the data about the grant into the token itself (so no back end store at all which is a significant advantage).
https://github.com/spring-projects/spring-security-oauth/blob/master/docs/oauth2.md
I am absolutely don't catch "no back end store at all". There are two cases in jwt:
symmetric key or shared secret (HMAC);
Verifier key is a shared secret and is available by /token_key URL.
Question 1: I should store shared secret on server for each registered user. Why "no back end store at all"?
asymmetric key (RS/ES);
/token_key returns public key (without principal).
Question 2: But why we use only one public key for all users? It is unable to generate more than one private key for the same public key in rsa, isn't it? Only one pair private key - public key is allowed in RSA.
I don't understand a flow and why "no back end store at all".
You do not use different keys per user but per Identity Provider.
Identity Provider signs a JWT with a key and you are able to validate it for each user without a backend lookup. For JWT validation you only need a key related to the Identity Provider - even if you store it on some DB, you could fetch it once and cache it. For assymetric keys, OIDC even defines a URL to fetch the public key(s) used for signature.
The key is used to trust the Identity Provider and thus implicitly the identities it provides.
This is quite good article on the topic:
https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/