Hi Jaap,
Very good points. I have the same opinion about what you said about
the meaning of scopes (and how people are actually using them), the
resource-scope relationship and the importance of a standardized way
of doing this form of authorization to address different use cases,
not only delegation. Like George said in one of his messages, both 1st
and 3rd party use cases could be considered by a solution like that.
I would love to see something based on OAuth like this:
#1) Client tries to access a protected resource. At this point, the
client does not yet have a bearer token or the bearer token is lacking
the required scopes/permissions. The resource server responds with:
/HTTP/1.1 403 Unauthorized /
/WWW-Authenticate: Bearer realm="example", error="invalid_token",
*claim_token*="accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC"/
The claim_token response parameter returned by the resource server
represents all the security constraints (e.g.: scopes) and information
(e.g.: contextual) that the client needs in order to obtain a valid
access token from the AS. This token can be built by the RS or even
use some endpoint at the AS, as UMA does. It can be just a reference
token too.
#2) Client obtains an access token from the token endpoint at the AS:
/POST /as/token.oauth2 HTTP/1.1/
/Host: as.example.com <http://as.example.com/>/
/Content-Type: application/x-www-form-urlencoded/
/grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Apermission/
/&resource=https%3A%2F%2Fbackend.example.com
<http://2fbackend.example.com/>%2Fapi%20/
/&*claim_token*=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC/
/&subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC/
/&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token/
The example above shows a client request to the token endpoint when
the client already has an access token and wants a new token with
permissions to access a resource.
#3) Just like any other OAuth grant type, the token endpoint responds
to the client as follows (success):
/HTTP/1.1 200 OK/
/Content-Type: application/json;charset=UTF-8/
/Cache-Control: no-store/
/Pragma: no-cache/
/
/
/{/
/"access_token":"2YotnFZFEjr1zCsicMWpAA"/
/"token_type":"example",/
/"expires_in":3600,/
/"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"/
/} /
/
/
#4) Clients can now access protected resources using the access token
with all permissions granted by the server
It is not coincidence the similarities with and the usage of
specs/drafts like token exchange, resource-indicator, UMA, Lodging
Intent Pattern,??or even ACE's "AS Request Creation Hints" message. The
point I would like to make is that we could leverage the
standards/specs that exist today to address the problem without
reinventing the wheel.
There are very interesting things in UMA specs that can be used here
too, such as the possibility to perform incremental authorization or
token upgrade, etc.
Regards.
Pedro Igor
On Thu, Apr 25, 2019 at 4:27 AM Jaap Francke
<jaap.francke=40iwelcome....@dmarc.ietf.org
<mailto:40iwelcome....@dmarc.ietf.org>> wrote:
Hi Torsten and others,
I just read your blog - having ???we need to re-think OAuth scopes???
in the title immediately drew my attention.
I find this interesting since I???m struggling with the concept of
scopes from time-to-time.
I???ll have to read the blog a few times more to get a good
understanding, but I would like to share some of my thoughts on
scopes.
I believe the OAuth scope concept has it???s limitations not only
for transactions but also for the more traditional ???resource??? concept.
RFC 6749 defines scopes as follows:
"The value of the scope parameter is expressed as a list of space-
???? delimited, case-sensitive strings.?? The strings are defined by the
???? authorization server.?? If the value contains multiple
space-delimited
???? strings, their order does not matter, and each string adds an
???? additional access range to the requested scope.???
I see 2 aspects in this definition:
- how the strings should look like is beyond the scope of the RFC
- each string adds an additional authorisation
Scopes are associated with access_tokens, which typically are
bearer tokens as defined by RFC 6750 as:
?????????? A security token with the property that any party in
possession of
?????????? the token (a "bearer") can use the token in any way that any
other
?????????? party in possession of it can.?? Using a bearer token does not
?????????? require a bearer to prove possession of cryptographic key
material
(proof-of-possession).???
This implies that every scope value should fully describe the
authorisation that is given. In my view that is rarely done, which
is the main reason why I find myself struggling with scope-concept.
Here we have a collection of examples, which demonstrate to me
that everyone is inventing their own wheels according to their
specfic needs:
https://brandur.org/oauth-scope
https://api.slack.com/docs/oauth-scopes
In various other (draft) standards I see bits and pieces that seem
to address this issue.
In UMA an authorisation is conceptually broken down into:
- subject -> requesting party
- verbs -> scopes of access
- object -> resource set.
I like this line of thinking and terminilogy. However, if
access_tokens are bearer tokens, I think ???subject??? is the bearer
of the token.
The most common practice, I think, is to use OIDC???s IDTokens to
contain a set of claims that scope the scope of the scope :-).
I mean that the claims in the ID-Tokens are used to scope the
objects as well as the verbs/scopes of access.
The core intention behind ID-token is to provide information about
the authenticated user and not necessarily about the resources
that are accessed. In practice, claims about the authenticated
users indicate which resources (photos) can be accessed at the
resource server.
My understanding of this draft
https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02
is that the object/resource aspect of authorisation is taken
somewhat out of the scope and put into a dedicated parameter.
Although (using the example from RFC 6749) the resource parameter
indicates theresource server (or application,
API, etc.) rather than an individual resource that is stored at
the resource server. So additional scoping of object/resource set
is still needed in addition to the resource parameter.
Furthermore,
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-12??makes
some interesting statements that are relevant in my view:
The section on Access Token privilege restriction says "access
tokens SHOULD be restricted to certain resources
and actions on resource servers or resources.??? So the OAuth
scope-string still needs to somehow indicate the resource-scope of
the privilege that is communicated.
"The client needs to tell the authorization server, at which URL it
will use the access token it is requesting. It could use the
mechanism proposed [I-D.ietf-oauth-resource-indicators
<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-12#ref-I-D.ietf-oauth-resource-indicators>]
or encode the
information in the scope value.???
I???m not sure which point I???m trying to make; i guess the need for
standardisation how to use and define OAuth-scopes.
I like the Lodging Intent Pattern and need to do some more
reading/thinking about the structured-scope and pushed request
objects.
I feel these concepts are not only relevant for authorisation of
transactions, but also for any access that needs authorisation.
I???m not sure if i express myself clearly, nevertheless any
feedback is welcome, if not alone to get my understanding of the
various concepts on a higher level.
Thanks in advance, kind regards
Jaap
Message: 1
Date: Wed, 24 Apr 2019 19:08:25 +0200
From: Torsten Lodderstedt <tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net>>
To: Sascha Preibisch <saschapreibi...@gmail.com
<mailto:saschapreibi...@gmail.com>>
Cc: oauth <oauth@ietf.org <mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
Message-ID: <2997b550-c82b-4d3a-9639-15a004f2f...@lodderstedt.net
<mailto:2997b550-c82b-4d3a-9639-15a004f2f...@lodderstedt.net>>
Content-Type: text/plain;charset=utf-8
Hi Sascha,
I see. I assume every element within the structured scope element
to be an independent scope (value) object and intended to use the
name of that object as kind of content type definition.
In my last example, the scope is defined as
????"structured_scope":{
??????????"sign":{
????????????????"credentialID":"qes_eidas",
????????????????"documentDigests":[
??????????????????????{
????????????????????????????"hash":
????????????????????????????????"sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
????????????????????????????"label":"Mobile Subscription Contract"
??????????????????????}
????????????????],
????????????????"hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
??????????},
??????????"payment":{
????????????????"type":"sepa-credit-transfer",
????????????????"instructedAmount":{
??????????????????????"currency":"EUR",
??????????????????????"amount":"123.50"
????????????????},
????????????????"debtorAccount":{
??????????????????????"iban":"DE40100100103307118608"
????????????????},
????????????????"creditorName":"Merchant123",
????????????????"creditorAccount":{
??????????????????????"iban":"DE02100100109307118603"
????????????????},
????????????????"remittanceInformationUnstructured":"new Smartphone"
??????????}
This means ?sign" and ?payment" would determine the scheme of the
respective object.
What do you think?
best regards,
Torsten.
On 23. Apr 2019, at 17:14, Sascha Preibisch
<saschapreibi...@gmail.com <mailto:saschapreibi...@gmail.com>>
wrote:
Hi Torsten!
If 'structured_scope' would become a generic field for application
specific content, I believe an indicator for the type of content
would
be needed on the long run. That is what I meant my 'profile'. I hope
this helps!
Thank you,
Sascha
Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>>:
Hi Sascha,
Am 22.04.2019 um 20:34 schrieb Sascha Preibisch
<saschapreibi...@gmail.com <mailto:saschapreibi...@gmail.com>>:
Thank you for the article, Torsten!
my pleasure :-)
I like that 'scope' is out of the game for these kinds of
authorizations.
What I can see for the general use case is a required identifier
within the 'structures_scope' document that identifies the
profile it
should be used for.
What does profile mean in this context?
best regards,
Torsten.
Thank you,
Sascha
Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>>:
Hi all,
I just published an article about the subject at:
https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
<https://medium..com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948>
I look forward to getting your feedback.
kind regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
------------------------------
Subject: Digest Footer
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
------------------------------
End of OAuth Digest, Vol 126, Issue 58
**************************************
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
