To be clear, access tokens are opaque in OAuth and I don’t see any of us trying
to change that in the general case. Particular authorization servers may use
JWTs as an access token format, but that’s their private choice. I know of
other authorization servers that have the access token value be an index into a
local database table, which is just as legitimate a choice as using a
structured access token.
-- Mike
From: OAuth [mailto:[email protected]] On Behalf Of Brian Campbell
Sent: Friday, April 25, 2014 1:12 PM
To: Bill Burke
Cc: oauth
Subject: Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re:
draft-ietf-oauth-jwt-bearer Shepherd Write-up)
I think it is kind of assumed, yeah. And JWT as it is gives you everything you
need for that as long as the AS and RS can agree on keys, JWE and/or JWS, and
how the claims will look. I suspect that's what most deployments are doing with
JWT access tokens today. We are, or offer JWS + JWT access tokens as an option
in product anyway, and I believe many others are doing the same.
IHMO getting everyone to agree on the specific claims etc. needed for a
standardized JWT access token is a bit of a rat's nest, which is why there's
not been much progress in that area.
On Fri, Apr 25, 2014 at 1:51 PM, Bill Burke
<[email protected]<mailto:[email protected]>> wrote:
Thank you. Thats what I thought. Is it just assumed JWT would/might be used
an access token format for Bearer token auth? Or is there another draft
somewhere for that? Is anybody out there using JWS + JWT as a access token
format?
On 4/25/2014 2:59 PM, Brian Campbell wrote:
draft-ietf-oauth-jwt-bearer is only about interactions (client
authentication and JWT as an authorization grant) with the token
endpoint and doesn't define JWT style access tokens.
On Fri, Apr 25, 2014 at 12:51 PM, Bill Burke
<[email protected]<mailto:[email protected]>
<mailto:[email protected]<mailto:[email protected]>>> wrote:
Red Hat Keycloak [1] only supports basic auth for client
authentication as suggested in the OAuth 2 spec. But our access
tokens are JWS signed JWTs.
Does draft-ietf-oauth-jwt-bearer relate to OAuth Bearer token auth
[2]? Or is there another document I should be following? I'd like
to see what other claims are being discussed related to JWT-based
access tokens and may have some additional access token claims we've
been experimenting with others might be interested in.
Also, I'm not sure yet if we'll implement
draft-ietf-oauth-jwt-bearer to authenticate clients. A lot of our
initial users are more interested in public clients and/or the
implicit flow as they are writing a lot of pure javascript apps
served up by simple static web servers.
[1] http://keycloak.org
[2] http://tools.ietf.org/html/__rfc6750
<http://tools.ietf.org/html/rfc6750>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
