For what it's worth, we deployed such a system in 2011 using signed
JWTs, symmetric keys and supporting key rotation via the kid JWT header
field. The body of the JWT includes 'iss', 'exp', 'uid' (for the user),
'access_token' (AS specific opaque blob), and 'validation_url' (where to
validate the AS specific opaque blob).
The issuing AS would generate this JWT and sign it. The RS, then
validates the signature. If necessary, the RS then also validates the
opaque token with the issuing AS.
Of course, using encrypted JWTs may be a better solution these days:)
Thanks,
George
On 3/13/16 4:44 PM, Mike Schwartz wrote:
I like the idea of an encrypted JWT... I guess if there are multiple
AS's, how would you know which key to use? Cycle through each key? Are
you suggesting maybe use a non-encrypted JWT that contains an
encrypted JWT as a value? Something like
{"iss": "https://example.com";,
"token": "fjbfgy5Fdx8ybx0.."
}
Are there any OAuth2 profiles to standardize this approach?
- Mike
--------------------------
Michael Schwartz
Gluu
Founder / CEO
m...@gluu.org
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
