Re: [OAUTH-WG] OAuth Digest, Vol 89, Issue 44

[jo turner <[e-mail]>]

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: [e-mail]<mailto:[e-mail]>
Sent: ‎15/‎03/‎2016 13:11
To: [e-mail]<mailto:[e-mail]>
Subject: OAuth Digest, Vol 89, Issue 44

Send OAuth mailing list submissions to
        [e-mail]

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
        [e-mail]

You can reach the person managing the list at
        [e-mail]

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 <[e-mail]>
To: [e-mail]
Subject: Re: [OAUTH-WG] Client Credentials flow and Client
        Registrations
Message-ID: <[e-mail]>
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

On 3/15/2016 8:37 AM, Sergey Beryozkin wrote:
> 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
> understand about it:
>
> 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
> access token:
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth



------------------------------

Message: 2
Date: Tue, 15 Mar 2016 13:01:16 +0000
From: Sergey Beryozkin <[e-mail]>
To: [e-mail]
Subject: [OAUTH-WG] When does RS not require token introspection ?
Message-ID: <[e-mail]>
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 <[e-mail]>
To: Sergey Beryozkin <[e-mail]>
Cc: [e-mail]
Subject: Re: [OAUTH-WG] Client Credentials flow and Client
        Registrations
Message-ID: <[e-mail]>
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.

> On Mar 15, 2016, at 9:37 AM, Sergey Beryozkin <[e-mail]> wrote:
>
> 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 understand about it:
>
> 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 access token:
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth

-------------- next part --------------
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 <[e-mail]>
To: Sergey Beryozkin <[e-mail]>, [e-mail]
Subject: Re: [OAUTH-WG] When does RS not require token introspection ?
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed

The access tokens are opaque to the client, not the RS.

  -- Justin

On 3/15/2016 9:01 AM, Sergey Beryozkin wrote:
> 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
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth



------------------------------

Subject: Digest Footer

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth


------------------------------

End of OAuth Digest, Vol 89, Issue 44
*************************************