[OAUTH-WG] Multiple authorization servers for one resource server

[Takahiko Kawasaki]

Hello,

I have a question.

If there exist multiple authorization servers that can issue access tokens
for one resource server, when the resource server receives an access token
from a client application, as the first step, the resource server has to
determine which authorization server to use for access token introspection.

Is there any standard way to determine which authorization server to use?

There may be several ways, for example:

(1) Embed information about the access token issuer in the access token.
(2) Add a request parameter to identify the access token issuer.
(3) Separate protected resource endpoints for each authorization server.

If there is a standard way, I'd like to know it.

Best Regards,
Takahiko Kawasaki

[Mike Schwartz]

Kawasaki-san,

This is a really good question: how to know the issuer of a bearer
token. Is there a header that could be added to specify the issuer, or
other important metadata?

- Mike


-------------------------------------
Michael Schwartz
Gluu
Founder / CEO
***@gluu.org

[Jim Willeke]

Why not register JWT as an access token type
<https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-types>
and then the the Issuer is implied?

--
-jim
Jim Willeke

Post by Mike Schwartz
Kawasaki-san,
This is a really good question: how to know the issuer of a bearer token.
Is there a header that could be added to specify the issuer, or other
important metadata?
- Mike
-------------------------------------
Michael Schwartz
Gluu
Founder / CEO
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Phil Hunt (IDM)]

A header might open another attack vector. Better to parse the jwt and look for the issuer assuming the jwt validates.

Phil

Why not register JWT as an access token type and then the the Issuer is implied?
--
-jim
Jim Willeke

Post by Mike Schwartz
Kawasaki-san,
This is a really good question: how to know the issuer of a bearer token. Is there a header that could be added to specify the issuer, or other important metadata?
- Mike
-------------------------------------
Michael Schwartz
Gluu
Founder / CEO
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Jim Willeke]

Would a header be a concern if TLS was used for transportation?

--
-jim
Jim Willeke

Post by Phil Hunt (IDM)
A header might open another attack vector. Better to parse the jwt and
look for the issuer assuming the jwt validates.
Phil
Why not register JWT as an access token type
<https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-types>
and then the the Issuer is implied?
--
-jim
Jim Willeke

Post by Mike Schwartz
Kawasaki-san,
This is a really good question: how to know the issuer of a bearer token.
Is there a header that could be added to specify the issuer, or other
important metadata?
- Mike
-------------------------------------
Michael Schwartz
Gluu
Founder / CEO
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Phil Hunt (IDM)]

Right now we are discussing mis-configured clients that have been convinced to use a token or rs endpoint that has been mitm. Adding a new parameter increases attack surface because the rs is now ignoring the token abd believing the header which may have been inserted.

Phil

Post by Jim Willeke
Would a header be a concern if TLS was used for transportation?
--
-jim
Jim Willeke

Post by Phil Hunt (IDM)
A header might open another attack vector. Better to parse the jwt and look for the issuer assuming the jwt validates.
Phil

Why not register JWT as an access token type and then the the Issuer is implied?
--
-jim
Jim Willeke

Post by Mike Schwartz
Kawasaki-san,
This is a really good question: how to know the issuer of a bearer token. Is there a header that could be added to specify the issuer, or other important metadata?
- Mike
-------------------------------------
Michael Schwartz
Gluu
Founder / CEO
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Justin Richer]

Agree with Phil, an additional header is a bad idea. It's not only yet
another thing that can be attacked, it's another thing that can get out
of sync by the client. Always assume OAuth clients are the dumbest parts
of the system.

-- Justin

Post by Phil Hunt (IDM)
Right now we are discussing mis-configured clients that have been
convinced to use a token or rs endpoint that has been mitm. Adding a
new parameter increases attack surface because the rs is now ignoring
the token abd believing the header which may have been inserted.
Phil

Post by Jim Willeke
Would a header be a concern if TLS was used for transportation?
--
-jim
Jim Willeke
On Sat, Mar 12, 2016 at 10:03 AM, Phil Hunt (IDM)
A header might open another attack vector. Better to parse the
jwt and look for the issuer assuming the jwt validates.
Phil

Why not register JWT as anaccess token type
<https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-types>
and then the the Issuer is implied?
--
-jim
Jim Willeke
Kawasaki-san,
This is a really good question: how to know the issuer of a
bearer token. Is there a header that could be added to
specify the issuer, or other important metadata?
- Mike
-------------------------------------
Michael Schwartz
Gluu
Founder / CEO
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Nat Sakimura]

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 and forms an unprotected segment. You would
have to treat the client as the smartest, in a bad way.

Post by Justin Richer
Agree with Phil, an additional header is a bad idea. It's not only yet
another thing that can be attacked, it's another thing that can get out of
sync by the client. Always assume OAuth clients are the dumbest parts of
the system.
-- Justin
Right now we are discussing mis-configured clients that have been
convinced to use a token or rs endpoint that has been mitm. Adding a new
parameter increases attack surface because the rs is now ignoring the token
abd believing the header which may have been inserted.
Phil
Would a header be a concern if TLS was used for transportation?
--
-jim
Jim Willeke

Post by Phil Hunt (IDM)
A header might open another attack vector. Better to parse the jwt and
look for the issuer assuming the jwt validates.
Phil
Why not register JWT as an access token type
<https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-types>
and then the the Issuer is implied?
--
-jim
Jim Willeke

Post by Mike Schwartz
Kawasaki-san,
This is a really good question: how to know the issuer of a bearer
token. Is there a header that could be added to specify the issuer, or
other important metadata?
- Mike
-------------------------------------
Michael Schwartz
Gluu
Founder / CEO
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Justin Richer]

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. The RS submits the token to the
introspection endpoint of the server identified in "iss", but only after
validating the signature and other basic bits of information. If the
introspection call comes back positive (and with the right scope,
client, and resource owner information), the resource is served.

-- Justin

Post by Takahiko Kawasaki
Hello,
I have a question.
If there exist multiple authorization servers that can issue access
tokens for one resource server, when the resource server receives an
access token from a client application, as the first step, the
resource server has to determine which authorization server to use for
access token introspection.
Is there any standard way to determine which authorization server to use?
(1) Embed information about the access token issuer in the access token.
(2) Add a request parameter to identify the access token issuer.
(3) Separate protected resource endpoints for each authorization server.
If there is a standard way, I'd like to know it.
Best Regards,
Takahiko Kawasaki
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Thomas Broyer]

Post by Justin Richer
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. The RS submits the token to the introspection endpoint
of the server identified in "iss", but only after validating the signature
and other basic bits of information. If the introspection call comes back
positive (and with the right scope, client, and resource owner
information), the resource is served.

But you cannot force every AS to emit access tokens that are JWTs.
For those AS that won't, then the RS would probably have to provide
endpoints (token endpoints?), one per AS, where the client could exchange
an AT from the AS for an AT specific to the RS (using token exchange with
unauthenticated clients?)

[Andrea Ceccanti]

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, scopes and basic identity information included seems to solve our
issues.

Thanks,
Andrea

Post by Justin Richer
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. The RS submits the token to the introspection endpoint
of the server identified in "iss", but only after validating the signature
and other basic bits of information. If the introspection call comes back
positive (and with the right scope, client, and resource owner
information), the resource is served.
-- Justin
Hello,
I have a question.
If there exist multiple authorization servers that can issue access tokens
for one resource server, when the resource server receives an access token
from a client application, as the first step, the resource server has to
determine which authorization server to use for access token introspection.
Is there any standard way to determine which authorization server to use?
(1) Embed information about the access token issuer in the access token.
(2) Add a request parameter to identify the access token issuer.
(3) Separate protected resource endpoints for each authorization server.
If there is a standard way, I'd like to know it.
Best Regards,
Takahiko Kawasaki
_______________________________________________
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Justin Richer]

We don’t include the scopes or identity information in the token itself, so as to prevent it from leaking to parties that shouldn’t need it.

The main benefit of introspection is liveness, but it also lets you reference data tied to the token that you don’t want to ship in the token itself.

At the end of the day, it’s a trade off as to what you want to put into the token and what you want attached as a reference. Good news is that you can do both together and use the strengths of each.

— Justin

Post by Takahiko Kawasaki
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, scopes and basic identity information included seems to solve our issues.
Thanks,
Andrea
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. The RS submits the token to the introspection endpoint of the server identified in "iss", but only after validating the signature and other basic bits of information. If the introspection call comes back positive (and with the right scope, client, and resource owner information), the resource is served.
-- Justin

Post by Takahiko Kawasaki
Hello,
I have a question.
If there exist multiple authorization servers that can issue access tokens for one resource server, when the resource server receives an access token from a client application, as the first step, the resource server has to determine which authorization server to use for access token introspection.
Is there any standard way to determine which authorization server to use?
(1) Embed information about the access token issuer in the access token.
(2) Add a request parameter to identify the access token issuer.
(3) Separate protected resource endpoints for each authorization server.
If there is a standard way, I'd like to know it.
Best Regards,
Takahiko Kawasaki
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

[Mike Schwartz]

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
***@gluu.org

[John Bradley]

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.1.6

The number of AS is not relevant for encryption to the RS unless you are using symmetric keys, and in that case there is likely only one key per AS (iss) so iss should be sufficient.

John B.

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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[George Fletcher]

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

Post by Mike Schwartz
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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Mike Schwartz]

This was the original requirement:

" multiple authorization servers that can issue access tokens for one
resource server, when the resource server receives an access token from
a client application, as the first step, the resource server has to
determine which authorization server to use for access token
introspection."

Not sure we're all on the same page after numerous responses...

So the fact that the token is an encrypted JWT is great... the question
is: who issued it? That's why I was thinking of a url encoded JWT with
the issuer + the encrypted token, such as {"iss":
"https://as.example.com", "token": "(encrypted JTW)"}

- Mike

[John Bradley]

Sorry your first email didn’t mention introspection.

I answered assuming a JWT.

A JWE can have the issuer in the envelope, so the recipient just needs to base64url decode the envelope to see who it issuer was and from that determine where to introspect it.

However if you are introspecting the token why bother making it a JWE, just send a regular JWS with a reference claim in the body that can be looked up by the AS during introspection.

If you are trying to do stateless introspection then just send a JWE access token containing the required claims and forget the introspection.

John B.

" multiple authorization servers that can issue access tokens for one resource server, when the resource server receives an access token from a client application, as the first step, the resource server has to determine which authorization server to use for access token introspection."
Not sure we're all on the same page after numerous responses...
So the fact that the token is an encrypted JWT is great... the question is: who issued it? That's why I was thinking of a url encoded JWT with the issuer + the encrypted token, such as {"iss": "https://as.example.com", "token": "(encrypted JTW)"}
- Mike
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth