I have a simple question about SSO flow with JWT
Let's say we have separate Authorization Server, which provides the JWT to the client app/server and Resource server, where client trying to access with that token.
The question is, should Resource server validate token by itself (e.g. share private certificate with Auth Server) or should it request Auth Server to validate JWT for each client request?
The JWT specification was built with scalability in mind. The purpose of JWT's design is that any trusted app can validate a the signature block. If you care about performance then use a SHA-256 HMAC and validate the signature locally on each endpoint with a shared secret. Using an asymmetric signature for JWT creates overhead, but you can store the public key on endpoints that verify but not issue JWT, and then the private key on the central authority that issues tokens. This separation of concern between validation and issuing reduces the possibilities that the token creation process can be subverted by an adversary (Read: Defense-in-depth).
If you need to revoke tokens in real time, then need a central authority which validates each token. This works, but it defeats the purpose of JWT's design, and the system would be better off just issuing a cryptogrpahic nonce as the token.
Related
As documentation of NestJS for authentication using Passport JWT, the flow is as below:
Client login with username/password
If username/password is valid, JWT sign payload (use preconfigured secure key) to create access token and return this access token to client
Client use access token to request guarded resources
So if secure key to sign payload is hacked, the access token can be generated for ALL users without using password.
Is my above understand is correct? What is suggestion for more secure?
Thank you.
Yes, if the key is compromised, the attacker can generate keys for themselves.
Try to adopt a more secure storage for credentials. If it has some sort of key rotation mechanism, it would be even better. For example, I use AWS Secrets Manager for this purpose in my project.
I am new to JWT and hence trying to understand the intricacies and expectations when using JWT. In my case, I own the micro-service generating the JWT tokens. JWT supports RS256 and HS256 mechanisms. From what I understand, in case of RS256, I distribute the public key to my client. In case of HS256, I distribute the secret to my client.
Assuming I give access to either of these to my client, what is the expectation from the client? Should the client treat the token I passed back to them as immutable and they just send me the exact token back in the subsequent API calls? Or is it recommended/ okay for them to mutate the token and create a new one, for e.g. by changing things like audience in the token payload, and then for my server to verify the newly passed token? My server should be able to verify both tokens, but I don't know which is the recommended approach. If the recommended approach is for my client to not mutate the token, why do I need to distribute the keys to the client in the first place?
Do not distribute the key to the client. The client should not be able to modify the JWT access token. It should treat the token as opaque.
Only the resource server (exposing the API) that accepts the token should verify the signature.
In OAuth2, the client is the application getting the access token and using it to call an API server. It should not care about the token as long as it works to call the API.
The authorization server authenticates the user, gets the user's consent and issues the token to the client.
The client then uses the token to call the resource server (API) with the token in the Authorization header.
In your case, the authorization server and resource server may be the same, but they should not share signing keys with the client.
I'm building an Angular 2 application using SAML2 via the passport-wsfed-saml2 strategy https://github.com/auth0/passport-wsfed-saml2. When I receive a users info back from SAML I generate a JWT token which I use to authenticate a user on an API I am also writing.
So I have two servers, APP/Auth Server is serving my application as well as generating my JWT tokens and API Server has my API. Both servers have a copy of the JWT secret, so when a user sends a request from APP/Auth Server to the API Server I verify the token they sent with their request by verifying it with the secret.
Now for my questions, is it bad practice to have your app served from the same server you use to generate your JWT tokens? If so, what should I do here? Should I be doing more to authenticate a user on my API side?
Something about this just feels dirty....any help would be appreciated.
Having the application and authentication system in the same service is not a malpractice by itself. In general, decoupled services are recommended but this does not mean that the deployment can group services and of course depends on the context
If you are worried about sharing the secret key among servers, you can use an asymmetric key pair (private and public). The private key only needs to be known by the Auth Server in order to sign the JWT. The API Server can use the public key to verify tokens.
I have a requirement to secure my JAX-RS resources and only accept requests that originate from authorized mobile applications. Is this possible? How can this be done?
All of my resources are protected already with user authentication, the goal here is to reduce user ID fishing attempts. I know one solution would be to keep the response error with an invalid user ID generic, but the application is very large and at the moment this isn't possible.
One idea I came up with is to use JWT tokens signed with a shared secret. Then I could add an Authorization filter on the server to check the signature. If it doesn't validate then discard the request. Does this sound like a viable option?
My concern is the security of the shared secret on a mobile device, could it be compromised with a rooted device?
Using tokens is the preferred way. But the secret key is not shared. Only the server has access to it. That secret key is used to generate the message authentication code(MAC) of the JWT. Since secret key is only known by the server, no one else can generate a JWT with a valid signature. Secret may be persisted or application scoped.
Once a client is authenticated using credentials, server must send a signed JWT to the client.
That JWT must contains necessary information to identify the client and state(if necessary).
Then client send that token in a header field along with all the other requests.
Server validates the JWT using secret key and process the request.
Even though client can change the JWT body, he cannot get it verified. That's the whole point of using a signature.
I am a complete noob when it comes to security, authentication strategies. So I was reading this article about "Token Based Authentication":
https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication
I have 2 questions:
I don't understand why a middleman(or a hacker) would not be able to see the token being sent by the client and use the same to impersonate as that client/person to retrieve resources? What makes JSON Web Tokens / OAuth2 based authentications safer in that sense? If we use a onetime-use-only token every time, I would understand that even if the hacker can read the token he will not be able to use it for another request. But as the token stays the same until it expires, how is that a safer authentication strategy?
How does the server know that the token sent by the client is valid i.e something that the server exchanged with the client during login. Does the server store the token generated in a database or somewhere and keep updating the "last accessed timestamp" or something and keeps removing the tokens where last_accessed_time is > 1hour ago, to keep expiring it after 1 hour of inactivity?
I don't understand why a middleman (or a hacker) would not be able to see the token being sent by the client and use the same to impersonate as that client/person to retrieve resources?
JWT does not protect you to a man-in-the-middle (MITM) attack. If an attacker gets a valid token, can effectively impersonate. Even if the content is encrypted.
JWT should be used with a SSL/TLS connection to avoid MITM
What makes JSON Web Tokens / OAuth2 based authentications safer in that sense?
JWT is a token format, and oauth2 is a protocol. oauth2 can use jwt. Oauth2 is safer to the user using a third party site because credentials are only sent from the user to the main site, then the site issues a token that can be used by the third party site to authenticate user. The third party site never see the user credentials
But as the token stays the same until it expires, how is that a safer authentication strategy?
Read above. You need to protect your tokens to not be stolen: Mainly use HTTPS, or mitigate its effects: store in cookies with HttpOnly (if you do not need to access JWT content in client side), set expiration time short, rotate tokens...
How does the server know that the token sent by the client is valid i.e something that the server exchanged with the client during login.
The third part of a JWT like hhhh.pppp.ssss is the signature. The signature is performed with server private key over the header and payload (hhhh.pppp), an protects the content. If an attacker alters the content or the signature, the server will detect it verifying the signature and will reject the authentication.
Does the server store the token generated in a database or somewhere and keep updating the "last accessed timestamp" or something and keeps removing the tokens where last_accessed_time is > 1 hour ago, to keep expiring it after 1 hour of inactivity?
It is not needed. The signature is packed in the token itself (ssss), therefore it is said that JWT is self-contained
The server has a cryptographic secret key or a key pair, public and private. The token is signed and verified with the secret key (for HMAC symmetric keys), or signed with the private key and verified with the corresponding public key (for RSA asymmetric keys).
It is all about signing the token not encrypting the token. The server just verifies the signature, JWT is not encrypted (unless you implement it).
Dont store sensitive data in the token, cause it is not encrypted by default.