Thanks for posting this, Phil. It provides a concrete example of a way that
protected resource discovery could be added to authorization server metadata
discovery, and as such, should provide useful input for working group
discussions on this topic. It’s always great when someone takes the tim
Hello,
interesting thread, thanks.
Assuming the scopes are included in the token, the main purpose of call to
the introspection endpoint is to ensure
the token hasn't been revoked?
We are considering a deployment where a RS can trust multiple AS, and
having a JWT as access token, with
issuer, sc
As I have told Phil off list.
Discovery is the wrong place to try and provide security against man in the
middle attacks on the RS.
This requires the client to know what the RS URI is before retrieving the
information on the AS Configuration.
The proposal Mike and I have been working on requ
On Sun, Mar 13, 2016 at 2:03 AM Justin Richer wrote:
> What we've done in deployments is to combine JWT and introspection. You
> have all of your servers issue signed JWTs that include the "iss" (issuer)
> in the body, signed with the key of the AS. The tokens also include a
> random "jti" field.
This draft is a proposed alternate proposal for draft-ietf-oauth-discovery. As
such, it contains the same registry for OAuth Config Metadata as the authors
believe that both solutions are not required, or depending on WG discussion
they will be merged. The intent is to provide a simple complete
I would expect the RS would only have one or two keys that it has published for
encryption.
I would expect the encryptor to provide a key ID “kid” if the RS has published
more than one key (eg for key rotation) and they probably should anyway unless
size is unusually constrained.
See JWE 4.
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": "fjbfgy5F
The question is about how RS can find the issuer from a bearer token that
it received from the client. Obviously, a header from the AS does not work.
We would have to have some kind of structured token. It can be a JWS or
something proprietary to the trust framework.
Note: the client is untrusted
