jo turner
2016-03-22 10:48:20 UTC
Hi Sergey,
Not sure why I'm on the mailing list have I accidentally accessed this ,my phone was hacked a year or so ago but since then I think my data has synced with it and I have weird search history etc that isn't mine,if I found a flaw in security am I eligible for a reward
Sent from my Windows Phone
________________________________
From: oauth-***@ietf.org<mailto:oauth-***@ietf.org>
Sent: â15/â03/â2016 13:11
To: ***@ietf.org<mailto:***@ietf.org>
Subject: OAuth Digest, Vol 89, Issue 44
Send OAuth mailing list submissions to
***@ietf.org
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
oauth-***@ietf.org
You can reach the person managing the list at
oauth-***@ietf.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."
Today's Topics:
1. Re: Client Credentials flow and Client Registrations
(Justin Richer)
2. When does RS not require token introspection ? (Sergey Beryozkin)
3. Re: Client Credentials flow and Client Registrations
(John Bradley)
4. Re: When does RS not require token introspection ? (Justin Richer)
----------------------------------------------------------------------
Message: 1
Date: Tue, 15 Mar 2016 08:53:12 -0400
From: Justin Richer <***@mit.edu>
To: ***@ietf.org
Subject: Re: [OAUTH-WG] Client Credentials flow and Client
Registrations
Message-ID: <***@mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Is Alice the client here (the piece of software), or is Alice the
resource owner? If Alice is the resource owner, then you should
absolutely not be using the client credentials flow like this.
The client credentials flow is designed for cases where the client is
acting on its own behalf, not on behalf of any particular user. It's an
optimization of the canonical authorization code flow, where there is no
interaction with the resource owner because there is no resource owner
as a separate entity. It's most useful for backend systems that would
have traditionally used a developer key to get access to bulk data. If
you're using it for single-user access, you're doing it wrong.
Also, you should keep in mind that things that seem "simple" on the
surface are often simplified at the cost of making specific security
concessions and assumptions. The authorization code flow is "complex"
for very good reasons, all of them security focused. You should never
pick a different OAuth flow just because it looks simpler, you should
only pick them if you're within the use case that it was designed for,
and therefor the assumptions of its security patterns match.
We've seen a *ton* of problems with people picking the implicit flow in
the real world and using it with clients other than in-browser
applications that it was designed for. If you're not in that specific
space, you're taking on huge risks.
-- Justin
Message: 2
Date: Tue, 15 Mar 2016 13:01:16 +0000
From: Sergey Beryozkin <***@gmail.com>
To: ***@ietf.org
Subject: [OAUTH-WG] When does RS not require token introspection ?
Message-ID: <***@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi
After following the recent thread on multiple authorization servers, but
also reading some other related threads, I have a question related to
when the token introspection can be avoided.
My understanding has been that given that access tokens are opaque the
RS does not know anything about its content, hence that was the purpose
of the token introspection spec: provide an interoperable way for RS to
submit a token to AS and get the token data for RS to make a final
decision about this token.
I think if the access tokens are really opaque, i.e, they are sequences
RS can not look into, then having the introspection option is the only
way to check what the token is really about.
But the recent replies with respect to using JWS or JWE tokens have
confused me.
1. AccessToken as JWS JWT Token:
RS can easily look into it, but Justin mentioned that in one case they
first validate this JWS token and then forward it for some further
introspection. Why start introspecting if the token has been validated
and its content is visible ?
Perhaps because some token data which are sensitive are only visible in
the introspection response ? If yes then why use a self-contained token
if some more external data are associated with it.
2. AccessToken as JWE JWT Token: this option was mentioned a couple of
times recently, Jonh B. suggested in the other thread the introspection
may not be needed (sorry if I misread it).
The question here, how can RS deal with a JWE token, it would need to
share the decrypting key with AS.
So, is introspection needed only for the completely opaque tokens or it
is also needed for JWS and JWE tokens. I'd say it might be reasonable to
skip it in case of JWS, depending on the specific requirements (as the
expiry, issuer, will be typically set in JWS JWT), while with JWE I can
not see how RS can avoid introspecting unless it shares the
secret/private key with AS.
Thanks, Sergey
------------------------------
Message: 3
Date: Tue, 15 Mar 2016 10:05:07 -0300
From: John Bradley <***@ve7jtb.com>
To: Sergey Beryozkin <***@gmail.com>
Cc: ***@ietf.org
Subject: Re: [OAUTH-WG] Client Credentials flow and Client
Registrations
Message-ID: <C1D353A4-A7C3-4B5F-9DFD-***@ve7jtb.com>
Content-Type: text/plain; charset="us-ascii"
I think you may be confusing Client credentials flow with resource owner credentials flow.
If there is a resource owner in the flow use code. The resource owner credentials flow is a bad idea and only put in for backwards compatibility.
John B.
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4326 bytes
Desc: not available
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20160315/7d08b4d0/attachment.p7s>
------------------------------
Message: 4
Date: Tue, 15 Mar 2016 09:11:30 -0400
From: Justin Richer <***@mit.edu>
To: Sergey Beryozkin <***@gmail.com>, ***@ietf.org
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
Message-ID: <***@mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
The access tokens are opaque to the client, not the RS.
-- Justin
Subject: Digest Footer
_______________________________________________
OAuth mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------------------------------
End of OAuth Digest, Vol 89, Issue 44
*************************************
Not sure why I'm on the mailing list have I accidentally accessed this ,my phone was hacked a year or so ago but since then I think my data has synced with it and I have weird search history etc that isn't mine,if I found a flaw in security am I eligible for a reward
Sent from my Windows Phone
________________________________
From: oauth-***@ietf.org<mailto:oauth-***@ietf.org>
Sent: â15/â03/â2016 13:11
To: ***@ietf.org<mailto:***@ietf.org>
Subject: OAuth Digest, Vol 89, Issue 44
Send OAuth mailing list submissions to
***@ietf.org
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
oauth-***@ietf.org
You can reach the person managing the list at
oauth-***@ietf.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."
Today's Topics:
1. Re: Client Credentials flow and Client Registrations
(Justin Richer)
2. When does RS not require token introspection ? (Sergey Beryozkin)
3. Re: Client Credentials flow and Client Registrations
(John Bradley)
4. Re: When does RS not require token introspection ? (Justin Richer)
----------------------------------------------------------------------
Message: 1
Date: Tue, 15 Mar 2016 08:53:12 -0400
From: Justin Richer <***@mit.edu>
To: ***@ietf.org
Subject: Re: [OAUTH-WG] Client Credentials flow and Client
Registrations
Message-ID: <***@mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Is Alice the client here (the piece of software), or is Alice the
resource owner? If Alice is the resource owner, then you should
absolutely not be using the client credentials flow like this.
The client credentials flow is designed for cases where the client is
acting on its own behalf, not on behalf of any particular user. It's an
optimization of the canonical authorization code flow, where there is no
interaction with the resource owner because there is no resource owner
as a separate entity. It's most useful for backend systems that would
have traditionally used a developer key to get access to bulk data. If
you're using it for single-user access, you're doing it wrong.
Also, you should keep in mind that things that seem "simple" on the
surface are often simplified at the cost of making specific security
concessions and assumptions. The authorization code flow is "complex"
for very good reasons, all of them security focused. You should never
pick a different OAuth flow just because it looks simpler, you should
only pick them if you're within the use case that it was designed for,
and therefor the assumptions of its security patterns match.
We've seen a *ton* of problems with people picking the implicit flow in
the real world and using it with clients other than in-browser
applications that it was designed for. If you're not in that specific
space, you're taking on huge risks.
-- Justin
Hi All
I've alway been thinking of Client Credentials as being the simplest
flow but now that I'm looking at implementing it myself to be used in
the real productions, I'm realizing that there's something I do not
Do the clients using Client Credentials flow need to be
OAuth2-registered, even when such clients are already known to the
authentication system ?
For example, there might be some LDAP/etc entry for Alice (name,
password). Now a client is using a client credentials flow to get an
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
I hope that in this case no explicit registration (the one typically
required in redirection based flows) is needed, the client (Alice) has
been 'implicitly' registered (as far as the notion of OAuth2 client is
concerned) in LDAP/etc.
If the explicit registration with OAuth2 AS was still required in the
case above then it would lead to a fairly massive duplication of
effort (Alice is registered in Ldap, then also with OAuth2 AS), etc
Can someone clarify it please ?
Thanks, Sergey
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
------------------------------I've alway been thinking of Client Credentials as being the simplest
flow but now that I'm looking at implementing it myself to be used in
the real productions, I'm realizing that there's something I do not
Do the clients using Client Credentials flow need to be
OAuth2-registered, even when such clients are already known to the
authentication system ?
For example, there might be some LDAP/etc entry for Alice (name,
password). Now a client is using a client credentials flow to get an
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
I hope that in this case no explicit registration (the one typically
required in redirection based flows) is needed, the client (Alice) has
been 'implicitly' registered (as far as the notion of OAuth2 client is
concerned) in LDAP/etc.
If the explicit registration with OAuth2 AS was still required in the
case above then it would lead to a fairly massive duplication of
effort (Alice is registered in Ldap, then also with OAuth2 AS), etc
Can someone clarify it please ?
Thanks, Sergey
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Message: 2
Date: Tue, 15 Mar 2016 13:01:16 +0000
From: Sergey Beryozkin <***@gmail.com>
To: ***@ietf.org
Subject: [OAUTH-WG] When does RS not require token introspection ?
Message-ID: <***@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi
After following the recent thread on multiple authorization servers, but
also reading some other related threads, I have a question related to
when the token introspection can be avoided.
My understanding has been that given that access tokens are opaque the
RS does not know anything about its content, hence that was the purpose
of the token introspection spec: provide an interoperable way for RS to
submit a token to AS and get the token data for RS to make a final
decision about this token.
I think if the access tokens are really opaque, i.e, they are sequences
RS can not look into, then having the introspection option is the only
way to check what the token is really about.
But the recent replies with respect to using JWS or JWE tokens have
confused me.
1. AccessToken as JWS JWT Token:
RS can easily look into it, but Justin mentioned that in one case they
first validate this JWS token and then forward it for some further
introspection. Why start introspecting if the token has been validated
and its content is visible ?
Perhaps because some token data which are sensitive are only visible in
the introspection response ? If yes then why use a self-contained token
if some more external data are associated with it.
2. AccessToken as JWE JWT Token: this option was mentioned a couple of
times recently, Jonh B. suggested in the other thread the introspection
may not be needed (sorry if I misread it).
The question here, how can RS deal with a JWE token, it would need to
share the decrypting key with AS.
So, is introspection needed only for the completely opaque tokens or it
is also needed for JWS and JWE tokens. I'd say it might be reasonable to
skip it in case of JWS, depending on the specific requirements (as the
expiry, issuer, will be typically set in JWS JWT), while with JWE I can
not see how RS can avoid introspecting unless it shares the
secret/private key with AS.
Thanks, Sergey
------------------------------
Message: 3
Date: Tue, 15 Mar 2016 10:05:07 -0300
From: John Bradley <***@ve7jtb.com>
To: Sergey Beryozkin <***@gmail.com>
Cc: ***@ietf.org
Subject: Re: [OAUTH-WG] Client Credentials flow and Client
Registrations
Message-ID: <C1D353A4-A7C3-4B5F-9DFD-***@ve7jtb.com>
Content-Type: text/plain; charset="us-ascii"
I think you may be confusing Client credentials flow with resource owner credentials flow.
If there is a resource owner in the flow use code. The resource owner credentials flow is a bad idea and only put in for backwards compatibility.
John B.
Hi All
Do the clients using Client Credentials flow need to be OAuth2-registered, even when such clients are already known to the authentication system ?
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
I hope that in this case no explicit registration (the one typically required in redirection based flows) is needed, the client (Alice) has been 'implicitly' registered (as far as the notion of OAuth2 client is concerned) in LDAP/etc.
If the explicit registration with OAuth2 AS was still required in the case above then it would lead to a fairly massive duplication of effort (Alice is registered in Ldap, then also with OAuth2 AS), etc
Can someone clarify it please ?
Thanks, Sergey
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
-------------- next part --------------Do the clients using Client Credentials flow need to be OAuth2-registered, even when such clients are already known to the authentication system ?
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
I hope that in this case no explicit registration (the one typically required in redirection based flows) is needed, the client (Alice) has been 'implicitly' registered (as far as the notion of OAuth2 client is concerned) in LDAP/etc.
If the explicit registration with OAuth2 AS was still required in the case above then it would lead to a fairly massive duplication of effort (Alice is registered in Ldap, then also with OAuth2 AS), etc
Can someone clarify it please ?
Thanks, Sergey
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4326 bytes
Desc: not available
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20160315/7d08b4d0/attachment.p7s>
------------------------------
Message: 4
Date: Tue, 15 Mar 2016 09:11:30 -0400
From: Justin Richer <***@mit.edu>
To: Sergey Beryozkin <***@gmail.com>, ***@ietf.org
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
Message-ID: <***@mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
The access tokens are opaque to the client, not the RS.
-- Justin
Hi
After following the recent thread on multiple authorization servers,
but also reading some other related threads, I have a question related
to when the token introspection can be avoided.
My understanding has been that given that access tokens are opaque the
RS does not know anything about its content, hence that was the
purpose of the token introspection spec: provide an interoperable way
for RS to submit a token to AS and get the token data for RS to make a
final decision about this token.
I think if the access tokens are really opaque, i.e, they are
sequences RS can not look into, then having the introspection option
is the only way to check what the token is really about.
But the recent replies with respect to using JWS or JWE tokens have
confused me.
RS can easily look into it, but Justin mentioned that in one case they
first validate this JWS token and then forward it for some further
introspection. Why start introspecting if the token has been validated
and its content is visible ?
Perhaps because some token data which are sensitive are only visible
in the introspection response ? If yes then why use a self-contained
token if some more external data are associated with it.
2. AccessToken as JWE JWT Token: this option was mentioned a couple of
times recently, Jonh B. suggested in the other thread the
introspection may not be needed (sorry if I misread it).
The question here, how can RS deal with a JWE token, it would need to
share the decrypting key with AS.
So, is introspection needed only for the completely opaque tokens or
it is also needed for JWS and JWE tokens. I'd say it might be
reasonable to skip it in case of JWS, depending on the specific
requirements (as the expiry, issuer, will be typically set in JWS
JWT), while with JWE I can not see how RS can avoid introspecting
unless it shares the secret/private key with AS.
Thanks, Sergey
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
------------------------------After following the recent thread on multiple authorization servers,
but also reading some other related threads, I have a question related
to when the token introspection can be avoided.
My understanding has been that given that access tokens are opaque the
RS does not know anything about its content, hence that was the
purpose of the token introspection spec: provide an interoperable way
for RS to submit a token to AS and get the token data for RS to make a
final decision about this token.
I think if the access tokens are really opaque, i.e, they are
sequences RS can not look into, then having the introspection option
is the only way to check what the token is really about.
But the recent replies with respect to using JWS or JWE tokens have
confused me.
RS can easily look into it, but Justin mentioned that in one case they
first validate this JWS token and then forward it for some further
introspection. Why start introspecting if the token has been validated
and its content is visible ?
Perhaps because some token data which are sensitive are only visible
in the introspection response ? If yes then why use a self-contained
token if some more external data are associated with it.
2. AccessToken as JWE JWT Token: this option was mentioned a couple of
times recently, Jonh B. suggested in the other thread the
introspection may not be needed (sorry if I misread it).
The question here, how can RS deal with a JWE token, it would need to
share the decrypting key with AS.
So, is introspection needed only for the completely opaque tokens or
it is also needed for JWS and JWE tokens. I'd say it might be
reasonable to skip it in case of JWS, depending on the specific
requirements (as the expiry, issuer, will be typically set in JWS
JWT), while with JWE I can not see how RS can avoid introspecting
unless it shares the secret/private key with AS.
Thanks, Sergey
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Subject: Digest Footer
_______________________________________________
OAuth mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------------------------------
End of OAuth Digest, Vol 89, Issue 44
*************************************