Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

JWT token SSO flow

Tags:

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.

enter image description here

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?

like image 482
silent-box Avatar asked Dec 26 '16 17:12

silent-box


People also ask

How does SSO work with JWT token?

Single sign-on is a mechanism that allows you to authenticate users in your systems and subsequently tell Zendesk that the user has been authenticated. If you use single sign-on with JSON Web Token (JWT), a user is automatically verified with the identity provider when they sign in.

What is JWT bearer token flow?

OAuth 2.0 JWT Bearer flow is used for server to server integration scenarios. This flow uses a certificate to sign the JWT request and doesn't require explicit user interaction. However, this flow does require prior approval of the client app.

How does JWT flow work?

With the OAuth 2.0 JWT bearer token flow, the client posts a JWT to the Salesforce OAuth token endpoint. Salesforce processes the JWT, which includes a digital signature, and issues an access token based on prior approval of the app.

Does SSO use tokens?

In SSO, this identity data takes the form of tokens which contain identifying bits of information about the user like a user's email address or a username.


1 Answers

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.

like image 144
rook Avatar answered Sep 23 '22 17:09

rook