I am using System.IdentityModel.Tokens.jwt library for jwt access token and after i call WriteToken, I can get back the access token value from ReadToken in another program. So the access token is not actually encrypted by default?
Not encrypted, but it should be signed so as to prevent tampering.
The jwt library has a ValidateToken method to check the token signature is correct using your token signing cert or key.
You would need to rely on SSL for encryption.
This Blog post gives a bit more detail on the difference between signing and encrypting the token.
If you think it sounds a little crazy for Oauth2.0 to rely on SSL then you wouldn't be alone. Check out Eran Hammer's thoughts on Oauth2.0 and why he walked away from it.
Related
I found one interesting article that has this illustration:
It says that:
API Gateway verifies access token for all incoming requests via introspection
But what does this mean?
it says that gateway goes to authorization server and validates token (JWT).
why is that needed?
if gateway has authorization server's public key, it can check token validity using signature just like every backend service, why is introspection needed and how is it done?
Depending on your Identity provider it can be done either way but there are trade offs.
If you validate the token locally then yes it can use public keys to do that and that's very efficient way, however downside is that if the token or signing keys are revoked then your token is still valid. With Remote check you have to bear the http overhead but that is more reliable.
Normally tokens are kept short lived and validated locally. But if your access token are long lived, your application require strict access controls or library doesn't support local validation then it's a good idea to check them remotely
I believe you are looking at this document.
What I understood from this Secure API Gateway is that the gateway is responsible for introspection and the back-end services will only check the token signature, which is less secure than introspection, but still a layer of security.
Introspection is necessary to validate the token information against the Authorization Server.
This is more secure, because the system can ensure that the token received is not malicious, expired and it is from an known source.
The details on how it is done are explained in RFC 7662.
Yes, the gateway could validate the token signature if it has access to the certificate.
I can't really tell why they choose the back-end server to do it, probably a project decision.
API Gateway primarily meant for routing the incoming calls to the corresponding MicroService Clusters.
In addition to that,it can also play a role to validate the token, so that only valid traffic is routed to the downstream servers (filtering malicious traffic).
The level of validation could be up to the product owner/architect decision. It could be as simple as validating against the list of in memory cached token or in depth validation on set of claims, digital signature verification, expiry time, audience claim etc.
You can view the set of claims inside the token using JWT decoder like https://devtoolzone.com/decoder/jwt
IMHO, there are two ways of signing a JWT token in OAuth2.0 - using symmetric hashing algorithm (like HS256) or using asymmetric hashing algorithm (RS256).
If we use asymmetric hashing algorithm such as RS256, do we require access token and refresh token? I believe they are not required as the whatever the claims present in the payload, the resource server can verify independently (as long as it knows the public key of the authorization server).
Then what is the use case for access token and refresh token? Is it required for symmetric hashing only?
Please help me in understanding this better. Thanks in advance.
The main idea of access token as JWT is that you don't have to go to the Authorization server every time. You can validate it by yourself by checking the signature. This can remove a lot of traffic from the Authorization server / DB.
You will want to use asymmetric hashing algorithm so the issuer has the private key and he is the only one allowed to issue the tokens and you can check the JWT with the public key.
The refresh token is what validated against a DB and can be revoked.
Every time the access token is expired you use the refresh token to get a new access token from the issuer.
If you plan on going to the Authorization server every time you want to check if the access token is valid, you can use symmetric hashing algorithm but then you miss the point of the JWT - you still have central place for all the authorization requests.
Can someone tell me how to send jwt authentication token for every rest request send from asp.net core to the web APi,
Does there is need to create a secret key to sign the token signature?
Can we just send the token without signing the token.
This is very broad question.
Short answers:
Tokens are usually sent in cookies. Certain solutions also store tokens in browser localstorage or sessionstorage and then add the token in every request header
Yes, signing the token is mandatory. Otherwise, the server won't have a way to determine if the token has been tampered by an attacker or client. Signing is required for security
But there are much more to it. Refer to the following for details:
https://stackoverflow.com/a/54258744/1235935
https://stackoverflow.com/a/54011649/1235935
https://www.rfc-editor.org/rfc/rfc7519
https://www.rfc-editor.org/rfc/rfc6749
I may have the wrong idea of how I should go about these things, but this is currently the case:
I have a WebApi service that accepts requests from Sharepoint Online (SPO), which have SAML2 token passed within. The SAML2 token is issued by SPO STS, and I will need to validate the token, and extract claims out of it.
My question is how do I validate the token? Is there a way to trust the STS somehow, so I can just verify the signature (possibly will have to decrypt the token as well) all in-place? If not, and I have to make another call to STS, what should be the endpoint to validate the token? I couldn't find much documentation on this.
If you're using O365 as STS or IdP and that provides the SAML2.0 Assertion to your service, then you have to get its X509Certificate (to verify the signature of received SAML2.0 Assertion) from metadata link: https://login.microsoftonline.com/<TenantDomainName>/FederationMetadata/2007-06/FederationMetadata.xml.
Make sure you retrieve X509Certificate from EntityDescriptor-> IDPSSODescriptor-> KeyDescriptor use="signing" -> KeyInfo-> X509Data-> X509Certificate.
Currently I'm learning about JWT and started with the token based authentication. I don't understand the sentence from the article:
Token based authentication works by ensuring that each request to a
server is accompanied by a signed token which the server verifies for
authenticity and only then responds to the request.
What is signed token? What does it mean to sign a token? I can't find the question on SO.
A signature is something that can be verified.
The main problem you're trying to solve is this: the server creates some arbitrary value, the token, which it gives to the client. The client subsequently gives it back to the server as proof of something (proof that they're authenticated, for instance). Now, how can the server be sure that the token is genuine, and the client didn't just make it up?
That's where the signature comes in. It's part of the token, and the server can verify that it had previously created that signature, and that the signature was created for this particular token. In a nutshell, the signature is a hash of the contents of the token plus a secret only the server possesses; to verify the signature the server repeats the hash of the token's contents and the secret only it has, and if it matches, that means the token's signature must have been created the same way which assures the two desired attributes of authenticity.
For the gnarly details of how a JWT signature is computed specifically, read the specification.