Ideas for an UMA extension for shorter flow
Uma-tarians, Here at Gluu we've been trying to come up with some options for API access management that leverage our UMA capabilities, while reducing the number of steps associated with the permission ticket flow. We came up with three options: 1) Eagerly issue an RPT token with permissions for resource sets where all scopes are satisfied. 2) Create a new token which just has the expiration and a list of scopes. Something like: { "active": true, "exp": 1256953732, "iat": 1256912345, "permissions": ["view", "manage" ] } And then the RS can evaluate if these scopes are sufficient for access. Maybe this token can be called the EAT (eager access token) or the GST (Granted Scope Token). 3) The RS takes the token above, and uses the OAuth2 token exchange endpoint, (see draft: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03 ) to swap out for a real RPT that specifies the scopes, or returns a permission ticket as normal if the scopes aren't suffcient. #1 has scale problems... especially if the AS has resource sets registered by RS's in many domains. It seems only appropriate for very small deployments in a single domain. #2 has minimal overlap with UMA. #3, I guess you have to wonder if it is really much better than the permission ticket flow. It moves complexity to the client, and in a best case, saves two steps (obtaining permission ticket, returning permission ticket). - Mike ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org
How is this different from just getting a plain OAuth token instead? Why do you have to invent something? Part of what drives this line of questioning for me is that #2 below looks suspiciously close to (but not compatible with) the standard core response from the introspection endpoint in RFC7662. Change “permissions”: [“view”, “manage”] to “scope”: “view manage” and you’re there. — Justin
On Dec 28, 2015, at 11:12 AM, Mike Schwartz <mike@gluu.org> wrote:
Uma-tarians,
Here at Gluu we've been trying to come up with some options for API access management that leverage our UMA capabilities, while reducing the number of steps associated with the permission ticket flow.
We came up with three options:
1) Eagerly issue an RPT token with permissions for resource sets where all scopes are satisfied.
2) Create a new token which just has the expiration and a list of scopes. Something like: { "active": true, "exp": 1256953732, "iat": 1256912345, "permissions": ["view", "manage" ] } And then the RS can evaluate if these scopes are sufficient for access. Maybe this token can be called the EAT (eager access token) or the GST (Granted Scope Token).
3) The RS takes the token above, and uses the OAuth2 token exchange endpoint, (see draft: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03 ) to swap out for a real RPT that specifies the scopes, or returns a permission ticket as normal if the scopes aren't suffcient.
#1 has scale problems... especially if the AS has resource sets registered by RS's in many domains. It seems only appropriate for very small deployments in a single domain.
#2 has minimal overlap with UMA.
#3, I guess you have to wonder if it is really much better than the permission ticket flow. It moves complexity to the client, and in a best case, saves two steps (obtaining permission ticket, returning permission ticket).
- Mike
------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Justin, Yes, you're right, we should do that. We started discussing the idea of the RS somehow exchanging this token for an RPT, but then the RS would have to push this RPT down to the client (perhaps in the header?). Anyway, it started getting complex, and we decided not to proceed with the token exchange for now. And we rejected #1 as potentially too likely to be misconfigured by users--it could lead to the leak of resource id's to third parties. - Mike On 2015-12-28 13:34, Justin Richer wrote:
How is this different from just getting a plain OAuth token instead? Why do you have to invent something?
Part of what drives this line of questioning for me is that #2 below looks suspiciously close to (but not compatible with) the standard core response from the introspection endpoint in RFC7662. Change “permissions”: [“view”, “manage”] to “scope”: “view manage” and you’re there.
— Justin
On Dec 28, 2015, at 11:12 AM, Mike Schwartz <mike@gluu.org> wrote:
Uma-tarians,
Here at Gluu we've been trying to come up with some options for API access management that leverage our UMA capabilities, while reducing the number of steps associated with the permission ticket flow.
We came up with three options:
1) Eagerly issue an RPT token with permissions for resource sets where all scopes are satisfied.
2) Create a new token which just has the expiration and a list of scopes. Something like: { "active": true, "exp": 1256953732, "iat": 1256912345, "permissions": ["view", "manage" ] } And then the RS can evaluate if these scopes are sufficient for access. Maybe this token can be called the EAT (eager access token) or the GST (Granted Scope Token).
3) The RS takes the token above, and uses the OAuth2 token exchange endpoint, (see draft: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03 ) to swap out for a real RPT that specifies the scopes, or returns a permission ticket as normal if the scopes aren't suffcient.
#1 has scale problems... especially if the AS has resource sets registered by RS's in many domains. It seems only appropriate for very small deployments in a single domain.
#2 has minimal overlap with UMA.
#3, I guess you have to wonder if it is really much better than the permission ticket flow. It moves complexity to the client, and in a best case, saves two steps (obtaining permission ticket, returning permission ticket).
- Mike
------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org
UMA-tarians, We added support in the Gluu Server for local token introspection. A few notes are here: https://github.com/GluuFederation/oxAuth/issues/111 We decided to use the same signing algorithm as was registered for the id_token signing in OpenID Connect dynamic client registration, and re-publish this info in the UMA discovery endpoint. We also added a discovery value "rpt_as_jwt" to specify that local token introspection is in use. Feedback is welcome... are we missing something? - Mike
I’m confused about something: How is this “introspection”? Isn’t this just using a structure token (JWT)? You can use both together if you like (MITREid Connect has been doing this for years and HEART requires it), but you shouldn’t confuse a self-contained structured token (JWT) with an online token verification and information service (introspection). — Justin
On Dec 28, 2015, at 3:00 PM, Mike Schwartz <mike@gluu.org> wrote:
UMA-tarians,
We added support in the Gluu Server for local token introspection.
A few notes are here: https://github.com/GluuFederation/oxAuth/issues/111
We decided to use the same signing algorithm as was registered for the id_token signing in OpenID Connect dynamic client registration, and re-publish this info in the UMA discovery endpoint.
We also added a discovery value "rpt_as_jwt" to specify that local token introspection is in use.
Feedback is welcome... are we missing something?
- Mike
I'm using jargon consistent with the issue that was raised a while back. Google says introspection means: "the examination or observation of one's own mental and emotional processes" So I'm not sure the word really fits for either calling an API to get back a JWT, or decrypting it... - Mike On 2015-12-28 14:05, Justin Richer wrote:
I’m confused about something: How is this “introspection”? Isn’t this just using a structure token (JWT)? You can use both together if you like (MITREid Connect has been doing this for years and HEART requires it), but you shouldn’t confuse a self-contained structured token (JWT) with an online token verification and information service (introspection).
— Justin
On Dec 28, 2015, at 3:00 PM, Mike Schwartz <mike@gluu.org> wrote:
UMA-tarians,
We added support in the Gluu Server for local token introspection.
A few notes are here: https://github.com/GluuFederation/oxAuth/issues/111
We decided to use the same signing algorithm as was registered for the id_token signing in OpenID Connect dynamic client registration, and re-publish this info in the UMA discovery endpoint.
We also added a discovery value "rpt_as_jwt" to specify that local token introspection is in use.
Feedback is welcome... are we missing something?
- Mike
-- ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org
I would argue that the issue raised was using incorrect terminology as well, since we have an RFC that claims the term in this space and context: https://tools.ietf.org/html/rfc7662 <https://tools.ietf.org/html/rfc7662> Is this more limited than the dictionary definition? Yes, but this happens with terms all the time. “Token” is also defined in a lot of different ways but it means something very specific in this context, and using it to mean something else (that might otherwise be valid definition of token) is confusing in the OAuth/UMA/OIDC context. For a concrete example, FIDO and OAuth both have “tokens” but they mean very, very different things. FWIW, I didn’t coin the term introspection, but a number of people were using it to describe this process when I pulled the original draft together. The idea was that the authorization server is being asked to look into its own internal state to figure out what the token is good for (introspect) and report on its findings, all via an API. That was reasonable enough, so I ran with it and the community accepted it. — Justin
On Dec 28, 2015, at 3:24 PM, Mike Schwartz <mike@gluu.org> wrote:
I'm using jargon consistent with the issue that was raised a while back.
Google says introspection means: "the examination or observation of one's own mental and emotional processes"
So I'm not sure the word really fits for either calling an API to get back a JWT, or decrypting it...
- Mike
On 2015-12-28 14:05, Justin Richer wrote:
I’m confused about something: How is this “introspection”? Isn’t this just using a structure token (JWT)? You can use both together if you like (MITREid Connect has been doing this for years and HEART requires it), but you shouldn’t confuse a self-contained structured token (JWT) with an online token verification and information service (introspection). — Justin
On Dec 28, 2015, at 3:00 PM, Mike Schwartz <mike@gluu.org> wrote: UMA-tarians, We added support in the Gluu Server for local token introspection. A few notes are here: https://github.com/GluuFederation/oxAuth/issues/111 We decided to use the same signing algorithm as was registered for the id_token signing in OpenID Connect dynamic client registration, and re-publish this info in the UMA discovery endpoint. We also added a discovery value "rpt_as_jwt" to specify that local token introspection is in use. Feedback is welcome... are we missing something? - Mike
-- ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org
For a long time, longer than the Token Introspection spec existed, a number of communities (ours included) have talked about "locally introspecting" a token, exactly as Mike has described. But of course the definition in the Token Introspection spec -- which we reference, of course -- defined the term itself, and is unambiguous. So another term would seem to be best. The ACE OAuth draft <https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/?include_text=1> seems to talk about "validation of a self-contained token" -- not bad, though a mouthful. Any other thoughts? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Mon, Dec 28, 2015 at 12:41 PM, Justin Richer <jricher@mit.edu> wrote:
I would argue that the issue raised was using incorrect terminology as well, since we have an RFC that claims the term in this space and context:
https://tools.ietf.org/html/rfc7662
Is this more limited than the dictionary definition? Yes, but this happens with terms all the time. “Token” is also defined in a lot of different ways but it means something very specific in this context, and using it to mean something else (that might otherwise be valid definition of token) is confusing in the OAuth/UMA/OIDC context. For a concrete example, FIDO and OAuth both have “tokens” but they mean very, very different things.
FWIW, I didn’t coin the term introspection, but a number of people were using it to describe this process when I pulled the original draft together. The idea was that the authorization server is being asked to look into its own internal state to figure out what the token is good for (introspect) and report on its findings, all via an API. That was reasonable enough, so I ran with it and the community accepted it.
— Justin
On Dec 28, 2015, at 3:24 PM, Mike Schwartz <mike@gluu.org> wrote:
I'm using jargon consistent with the issue that was raised a while back.
Google says introspection means: "the examination or observation of one's own mental and emotional processes"
So I'm not sure the word really fits for either calling an API to get back a JWT, or decrypting it...
- Mike
On 2015-12-28 14:05, Justin Richer wrote:
I’m confused about something: How is this “introspection”? Isn’t this just using a structure token (JWT)? You can use both together if you like (MITREid Connect has been doing this for years and HEART requires it), but you shouldn’t confuse a self-contained structured token (JWT) with an online token verification and information service (introspection). — Justin
On Dec 28, 2015, at 3:00 PM, Mike Schwartz <mike@gluu.org> wrote: UMA-tarians, We added support in the Gluu Server for local token introspection. A few notes are here: https://github.com/GluuFederation/oxAuth/issues/111 We decided to use the same signing algorithm as was registered for the id_token signing in OpenID Connect dynamic client registration, and re-publish this info in the UMA discovery endpoint. We also added a discovery value "rpt_as_jwt" to specify that local token introspection is in use. Feedback is welcome... are we missing something? - Mike
-- ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
"self-contained token validation" is ok by me... - Mike On 2016-01-04 14:07, Eve Maler wrote:
For a long time, longer than the Token Introspection spec existed, a number of communities (ours included) have talked about "locally introspecting" a token, exactly as Mike has described. But of course the definition in the Token Introspection spec -- which we reference, of course -- defined the term itself, and is unambiguous.
So another term would seem to be best. The ACE OAuth draft [3] seems to talk about "validation of a self-contained token" -- not bad, though a mouthful. Any other thoughts?
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Mon, Dec 28, 2015 at 12:41 PM, Justin Richer <jricher@mit.edu> wrote:
I would argue that the issue raised was using incorrect terminology as well, since we have an RFC that claims the term in this space and context:
https://tools.ietf.org/html/rfc7662 [1]
Is this more limited than the dictionary definition? Yes, but this happens with terms all the time. “Token” is also defined in a lot of different ways but it means something very specific in this context, and using it to mean something else (that might otherwise be valid definition of token) is confusing in the OAuth/UMA/OIDC context. For a concrete example, FIDO and OAuth both have “tokens” but they mean very, very different things.
FWIW, I didn’t coin the term introspection, but a number of people were using it to describe this process when I pulled the original draft together. The idea was that the authorization server is being asked to look into its own internal state to figure out what the token is good for (introspect) and report on its findings, all via an API. That was reasonable enough, so I ran with it and the community accepted it.
— Justin
On Dec 28, 2015, at 3:24 PM, Mike Schwartz <mike@gluu.org> wrote:
I'm using jargon consistent with the issue that was raised a while back.
Google says introspection means: "the examination or observation of one's own mental and emotional processes"
So I'm not sure the word really fits for either calling an API to get back a JWT, or decrypting it...
- Mike
On 2015-12-28 14:05, Justin Richer wrote: I’m confused about something: How is this “introspection”? Isn’t this just using a structure token (JWT)? You can use both together if you like (MITREid Connect has been doing this for years and HEART requires it), but you shouldn’t confuse a self-contained structured token (JWT) with an online token verification and information service (introspection). — Justin On Dec 28, 2015, at 3:00 PM, Mike Schwartz <mike@gluu.org> wrote: UMA-tarians, We added support in the Gluu Server for local token introspection. A few notes are here: https://github.com/GluuFederation/oxAuth/issues/111 [2] We decided to use the same signing algorithm as was registered for the id_token signing in OpenID Connect dynamic client registration, and re-publish this info in the UMA discovery endpoint. We also added a discovery value "rpt_as_jwt" to specify that local token introspection is in use. Feedback is welcome... are we missing something? - Mike
-- ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma [4]
Links: ------ [1] https://tools.ietf.org/html/rfc7662 [2] https://github.com/GluuFederation/oxAuth/issues/111 [3] https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/?include_text=1 [4] http://kantarainitiative.org/mailman/listinfo/wg-uma
-- ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org
At UnboundID, we use the term self-contained tokens as well. Take care, Ishan Ishan Kumar | UnboundID <https://www.unboundid.com/> - Product Manager 512.600.7764 <//15126007764> | ishank@unboundid.com On Mon, Jan 4, 2016 at 2:23 PM, Mike Schwartz <mike@gluu.org> wrote:
"self-contained token validation" is ok by me...
- Mike
On 2016-01-04 14:07, Eve Maler wrote:
For a long time, longer than the Token Introspection spec existed, a number of communities (ours included) have talked about "locally introspecting" a token, exactly as Mike has described. But of course the definition in the Token Introspection spec -- which we reference, of course -- defined the term itself, and is unambiguous.
So another term would seem to be best. The ACE OAuth draft [3] seems to talk about "validation of a self-contained token" -- not bad, though a mouthful. Any other thoughts?
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Mon, Dec 28, 2015 at 12:41 PM, Justin Richer <jricher@mit.edu> wrote:
I would argue that the issue raised was using incorrect terminology
as well, since we have an RFC that claims the term in this space and context:
https://tools.ietf.org/html/rfc7662 [1]
Is this more limited than the dictionary definition? Yes, but this happens with terms all the time. “Token” is also defined in a lot of different ways but it means something very specific in this context, and using it to mean something else (that might otherwise be valid definition of token) is confusing in the OAuth/UMA/OIDC context. For a concrete example, FIDO and OAuth both have “tokens” but they mean very, very different things.
FWIW, I didn’t coin the term introspection, but a number of people were using it to describe this process when I pulled the original draft together. The idea was that the authorization server is being asked to look into its own internal state to figure out what the token is good for (introspect) and report on its findings, all via an API. That was reasonable enough, so I ran with it and the community accepted it.
— Justin
On Dec 28, 2015, at 3:24 PM, Mike Schwartz <mike@gluu.org> wrote:
I'm using jargon consistent with the issue that was raised a while back.
Google says introspection means: "the examination or observation of one's own mental and emotional processes"
So I'm not sure the word really fits for either calling an API to get back a JWT, or decrypting it...
- Mike
On 2015-12-28 14:05, Justin Richer wrote: I’m confused about something: How is this “introspection”? Isn’t this just using a structure token (JWT)? You can use both together if you like (MITREid Connect has been doing this for years and HEART requires it), but you shouldn’t confuse a self-contained structured token (JWT) with an online token verification and information service (introspection). — Justin On Dec 28, 2015, at 3:00 PM, Mike Schwartz <mike@gluu.org> wrote: UMA-tarians, We added support in the Gluu Server for local token introspection. A few notes are here: https://github.com/GluuFederation/oxAuth/issues/111 [2] We decided to use the same signing algorithm as was registered for the id_token signing in OpenID Connect dynamic client registration, and re-publish this info in the UMA discovery endpoint. We also added a discovery value "rpt_as_jwt" to specify that local token introspection is in use. Feedback is welcome... are we missing something? - Mike
-- ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma [4]
Links: ------ [1] https://tools.ietf.org/html/rfc7662 [2] https://github.com/GluuFederation/oxAuth/issues/111 [3] https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/?include_text=1 [4] http://kantarainitiative.org/mailman/listinfo/wg-uma
-- ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
participants (4)
-
Eve Maler -
Ishan Kumar -
Justin Richer -
Mike Schwartz