Subject: [OAUTH-WG] Why OAuth it self is not an authentication framework ?

From: Prabath Siriwardena <[email-masked]>
Date: Wed, 6 Feb 2013 01:22:59 +0530

FYI and for your comments..

http://blog.facilelogin.com/2013/02/why-oauth-it-self-is-not-authentication.html

Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

---

From: John Bradley <[email-masked]>
Date: Tue, 5 Feb 2013 13:36:32 -0700

OAuth is an Authorization protocol as many of us have pointed out.

The post is largely correct and based on one of mine.

John B.

On 2013-02-05, at 12:52 PM, Prabath Siriwardena <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Tue, 5 Feb 2013 15:41:58 -0500

Another very good writeup of this was published recently as well:

http://blogs.msdn.com/b/vbertocci/archive/2013/01/02/oauth-2-0-and-sign-in.aspx

This confusion seems to be a major sticking point among developers.

  -- Justin

---

From: Paul Madsen <[email-masked]>
Date: Tue, 05 Feb 2013 16:12:10 -0500

why pigeonhole it?

OAuth can be deployed with no authz semantics at all (or at least as 
little as any authn mechanism), e.g client creds grant type with no scopes

I agree that OAuth is not an *SSO* protocol.

On 2/5/13 3:36 PM, John Bradley wrote:
> On 2013-02-05, at 12:52 PM, Prabath Siriwardena <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> http://blog.facilelogin.com <http://blog.facilelogin.com/>
>> http://RampartFAQ.com <http://rampartfaq.com/>
>> [email-masked] <mailto:[email-masked]>

---

From: William Mills <[email-masked]>
Date: Tue, 5 Feb 2013 13:22:52 -0800 (PST)

There are some specific design mis-matches for OAuth as an authentication protocol, it's not what it's designed for and there are some problems you will run into.  Some have used it as such, but it's not a good general solution.

-bill

________________________________
 From: Paul Madsen <[email-masked]>
To: John Bradley <[email-masked]> 
Cc: "[email-masked] WG" <[email-masked]> 
Sent: Tuesday, February 5, 2013 1:12 PM
Subject: Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ?

why pigeonhole it? 

OAuth can be deployed with no authz semantics at all (or at least
      as little as any authn mechanism), e.g client creds grant type
      with no scopes

Thanks & Regards,
>>Prabath 
>>
>>
>>Mobile : +94 71 809 6732 
>>
>>http://blog.facilelogin.com/
>>http://rampartfaq.com/
>>https://www.ietf.org/mailman/listinfo/oauth
OAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/oauth

---

From: Tim Bray <[email-masked]>
Date: Tue, 5 Feb 2013 13:27:34 -0800

OIDC seems about the most plausible candidate for a “good general solution”
that I’m aware of.   -T

On Tue, Feb 5, 2013 at 1:22 PM, William Mills <[email-masked]>wrote:

> There are some specific design mis-matches for OAuth as an authentication
> protocol, it's not what it's designed for and there are some problems you
> will run into.  Some have used it as such, but it's not a good general
> solution.
>
> -bill
>
>   ------------------------------
> *From:* Paul Madsen <[email-masked]>
> *To:* John Bradley <[email-masked]>
> *Cc:* "[email-masked] WG" <[email-masked]>
> *Sent:* Tuesday, February 5, 2013 1:12 PM
> *Subject:* Re: [OAUTH-WG] Why OAuth it self is not an authentication
> framework ?
>
>  why pigeonhole it?
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Tue, 5 Feb 2013 22:27:12 +0000

I think this is becoming a largely academic / philosophical argument by this time.  The people who designed OAuth will likely point out that it was conceptualized as an authorization protocol to enable a RO to delegate access to a client to access its protected resources on some RS.  And of course this is the history of it.  And the RO and end-user were typically the same entity.  But get caught up in what it was envisioned to do vs. real life use cases that OAuth can solve (and is solving) beyond its initial use cases misses the point … because OAuth is gaining traction in the enterprise and will be used in all different sorts of ways, including authentication.

This is especially true of RESTful APIs within an enterprise where the RO and end-user are *not* the same: e.g. RO=enterprise and end-user=employee.  In this model the end-user is not authorizing anything when their client requests a token from the AS … they authenticate to the AS and the client gets an AT, which will likely be profiled by most enterprise deployments to look something like an OIDC id_token.  The AT will be presented to the RS which will examine the claims (user identity, LOA, etc.) and make authorization decisions based on business logic.  The AT has not authorized the user to do anything, it has only made an assertion that the user has been authenticated by the AS (sort of sounds a lot like an IdP now).

All this talked of OAuth being authorization and not authentication was extremely confusing to me when I first started looking at OAuth for my use cases, and I think at some point the authors of OAuth are going to have to recognize that their baby has grown up to be multi-faceted (and I mean this as a complement).  The abstractions left in the OAuth spec (while some have claimed of the lack of interoperability it will cause) will also enable it to be used in ways possibly still not envisioned by any of us.  I think as soon as we can stop trying to draw the artificial line around OAuth being “an authorization protocol” the better things will be.

I like to say that they authors had it right when they named it “OAuth” and not “OAuthR” ☺

-adam

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Bray
Sent: Tuesday, February 05, 2013 3:28 PM
To: William Mills
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ?

OIDC seems about the most plausible candidate for a “good general solution” that I’m aware of.   -T
On Tue, Feb 5, 2013 at 1:22 PM, William Mills <[email-masked]<mailto:[email-masked]>> wrote:
There are some specific design mis-matches for OAuth as an authentication protocol, it's not what it's designed for and there are some problems you will run into.  Some have used it as such, but it's not a good general solution.

-bill

________________________________
From: Paul Madsen <[email-masked]<mailto:[email-masked]>>
To: John Bradley <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]> WG" <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, February 5, 2013 1:12 PM
Subject: Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ?

why pigeonhole it?

OAuth can be deployed with no authz semantics at all (or at least as little as any authn mechanism), e.g client creds grant type with no scopes

John B.

On 2013-02-05, at 12:52 PM, Prabath Siriwardena <[email-masked]<mailto:[email-masked]>> wrote:

Thanks & Regards,
Prabath

Mobile : +94 71 809 6732<tel:%2B94%2071%20809%206732>
http://blog.facilelogin.com/
http://rampartfaq.com/
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

OAuth mailing list

[email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Tue, 5 Feb 2013 16:28:24 -0700

I am not against using OAuth to build other protocols.

I am only concerned that when people build those things they perform the appropriate security analyses, and not make inappropriate assumptions about the underlying protocol.

You  can certainly use OAuth to authenticate a principal to a client or a client to a RS in lots of ways that will work.
When you do that you are creating a new protocol that needs to be looked at for security considerations, or you wind up introducing replay and substitution attacks that don't apply to pure OAuth.

OAuth is a framework to build things on, like TLS or HTTP.

John B.
On 2013-02-05, at 3:27 PM, Lewis Adam-CAL022 <[email-masked]> wrote:

> I like to say that they authors had it right when they named it “OAuth” and not “OAuthR” J
>  
> -adam
>  
> On Tue, Feb 5, 2013 at 1:22 PM, William Mills <[email-masked]> wrote:

---

From: William Mills <[email-masked]>
Date: Tue, 5 Feb 2013 16:48:32 -0800 (PST)

Why use OAuth when OpenID does everything that OAuth can do as an authentication method and does a few things much better?

Specifically OAuth lacks any defined way to:

-feed back any additional information like the real user ID (as opposed to what the entered)
-bound an authentication event in time
-provide any form of additional SSO payload like a display name for the user

there's probably other things.

It'll mostly work but there are things it doesn't do.  Could you solve some of the rest of this with token introspection or a user API that the RP could use to fetch user info, sure, but why rebuild OpenID when OpenID exists?

-bill

________________________________
 From: Lewis Adam-CAL022 <[email-masked]>
To: Tim Bray <[email-masked]>; William Mills <[email-masked]> 
Cc: "[email-masked] WG" <[email-masked]> 
Sent: Tuesday, February 5, 2013 2:27 PM
Subject: RE: [OAUTH-WG] Why OAuth it self is not an authentication framework ?

 

 
-adam
 
From:[email-masked] [mailto:[email-masked]] On Behalf Of Tim Bray
Sent: Tuesday, February 05, 2013 3:28 PM
To: William Mills
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ?

-bill

From:Paul Madsen <[email-masked]>
 
why pigeonhole it?

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Wed, 6 Feb 2013 16:05:08 +0000

Hi Bill,

My reason for using OAuth rather than OIDC is because the id_token in OIDC is audience restricted to the client.  This was clearly intended for WebSSO / authentication to a client running on a web server.  It does not help the case where the user of a RESTful native client want to authenticate to a RESTful web service.

I agree that OAuth lacks a “defined” way to communicate what is in the AT (as OAuth does not define the content of the AT), but within an enterprise domain this is easy to solve by profiling.  And in any implementation of OAuth on the Internet, the AT must at some level identify the user to the RS.  Otherwise how else would the RS know who’s protected resources the client is trying to access?  Now whether the RS learns that through introspection or by parsing a JWT-structured AT is of course not defined.  But at the end of the day, the AT definitely (in all cases that I can think of) identifies the user.

I am open minded to using OIDC if in the future if the client can request an id_token that is audience restricted to the RS it is going to communicate.  In other words, yes I agree that OIDC is the preferred mechanism for performing “user authentication to a client,” but I also argue that OAuth is the best method to perform “user authentication to an RS” (if you want to get your RS out of the password consumption business).  I am not at all advocating OAuth for authentication to a client.

-adam

From: William Mills [mailto:[email-masked]]
Sent: Tuesday, February 05, 2013 6:49 PM
To: Lewis Adam-CAL022; Tim Bray
Cc: "WG <[email-masked]>"@il06exr02.mot.com
Subject: Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ?

-    feed back any additional information like the real user ID (as opposed to what the entered)
-    bound an authentication event in time
-    provide any form of additional SSO payload like a display name for the user

-bill

-adam

-bill

why pigeonhole it?

John B.

Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

OAuth mailing list

---

From: John Bradley <[email-masked]>
Date: Wed, 6 Feb 2013 09:21:48 -0700

Adam,

We have made some changes in the latest draft to address some input from Google that I think may also address your need to using the id_token in an assertion or possibly as an access token to a federated RS.

I can go over it with you if you like.

John B.

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 6 Feb 2013 18:49:19 -0700

Lewis,

Specifically, we have defined the following to the id_token.

issREQUIRED. Issuer Identifier for the Issuer of the response.subREQUIRED.
Subject identifier. A locally unique and never reassigned identifier within
the Issuer for the End-User, which is intended to be consumed by the
Client. e.g. 24400320 or AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4. It MUST
NOT exceed 255 ASCII characters in length.audREQUIRED. Audience that this
ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the
Client.azpOPTIONAL. Authorized Party. This member identifies an OAuth 2.0
client authorized to use this ID Token as an OAuth access token. This Claim
is only needed when the Authorized Party is different than the Client that
requested the ID Token. It MUST contain the client_id of the authorized
party.
This 'azp' is the new thing. I proposed it as 'reg' (after 'registered
instrument/token) and Google is using 'cid' (client id) but it ended up
'azp' (authorized party, which I have a hard time remembering :-) So, if
you want to use id_token to authenticate the client to a resource server,
then you put the client_id (that the resource server understands) into azp,
and the identifier of the resource server into aud.

Best,

Nat

2013/2/6 John Bradley <[email-masked]>

> Adam,
>
> We have made some changes in the latest draft to address some input from
> Google that I think may also address your need to using the id_token in an
> assertion or possibly as an access token to a federated RS.
>
> Hi Bill,****
> My reason for using OAuth rather than OIDC is because the id_token in OIDC
> is audience restricted to the client.  This was clearly intended for WebSSO
> / authentication to a client running on a web server.  It does not help the
> case where the user of a RESTful native client want to authenticate to a
> RESTful web service. ****
>
> I agree that OAuth lacks a “defined” way to communicate what is in the AT
> (as OAuth does not define the content of the AT), but within an enterprise
> domain this is easy to solve by profiling.  And in any implementation of
> OAuth on the Internet, the AT must at some level identify the user to the
> RS.  Otherwise how else would the RS know who’s protected resources the
> client is trying to access?  Now whether the RS learns that through
> introspection or by parsing a JWT-structured AT is of course not defined.
> But at the end of the day, the AT definitely (in all cases that I can think
> of) identifies the user. ****
>
> I am open minded to using OIDC if in the future if the client can request
> an id_token that is audience restricted to the RS it is going to
> communicate.  In other words, yes I agree that OIDC is the preferred
> mechanism for performing “user authentication to a client,” but I also
> argue that OAuth is the best method to perform “user authentication to an
> RS” (if you want to get your RS out of the password consumption business).
> I am not at all advocating OAuth for authentication to a client. ****
>
> -adam****
>
> *From:* William Mills [mailto:[email-masked]]
> *Sent:* Tuesday, February 05, 2013 6:49 PM
> *To:* Lewis Adam-CAL022; Tim Bray
> *Cc:* "WG <[email-masked]>"@il06exr02.mot.com
> framework ?****
> ** **
> Why use OAuth when OpenID does everything that OAuth can do as an
> authentication method and does a few things much better?****
>
> Specifically OAuth lacks any defined way to:****
>
> -    feed back any additional information like the real user ID (as
> opposed to what the entered)****
> -    bound an authentication event in time****
> -    provide any form of additional SSO payload like a display name for
> the user****
>
> there's probably other things.****
>
> It'll mostly work but there are things it doesn't do.  Could you solve
> some of the rest of this with token introspection or a user API that the RP
> could use to fetch user info, sure, but why rebuild OpenID when OpenID
> exists?****
>
> -bill****
>
>
> *From:* Lewis Adam-CAL022 <[email-masked]>
> *To:* Tim Bray <[email-masked]>; William Mills <[email-masked]>
>
> *Sent:* Tuesday, February 5, 2013 2:27 PM
> *Subject:* RE: [OAUTH-WG] Why OAuth it self is not an authentication
> framework ?****
>
> I think this is becoming a largely academic / philosophical argument by
> this time.  The people who designed OAuth will likely point out that it was
> conceptualized as an authorization protocol to enable a RO to delegate
> access to a client to access its protected resources on some RS.  And of
> course this is the history of it.  And the RO and end-user were typically
> the same entity.  But get caught up in what it was envisioned to do vs.
> real life use cases that OAuth can solve (and is solving) beyond its
> initial use cases misses the point … because OAuth is gaining traction in
> the enterprise and will be used in all different sorts of ways, including
> authentication. ****
>  ****
> This is especially true of RESTful APIs within an enterprise where the RO
> and end-user are **not** the same: e.g. RO=enterprise and
> end-user=employee.  In this model the end-user is not authorizing anything
> when their client requests a token from the AS … they authenticate to the
> AS and the client gets an AT, which will likely be profiled by most
> enterprise deployments to look something like an OIDC id_token.  The AT
> will be presented to the RS which will examine the claims (user identity,
> LOA, etc.) and make authorization decisions based on business logic.  The
> AT has not authorized the user to do anything, it has only made an
> assertion that the user has been authenticated by the AS (sort of sounds a
> lot like an IdP now).****
>  ****
> All this talked of OAuth being authorization and not authentication was
> extremely confusing to me when I first started looking at OAuth for my use
> cases, and I think at some point the authors of OAuth are going to have to
> recognize that their baby has grown up to be multi-faceted (and I mean this
> as a complement).  The abstractions left in the OAuth spec (while some have
> claimed of the lack of interoperability it will cause) will also enable it
> to be used in ways possibly still not envisioned by any of us.  I think as
> soon as we can stop trying to draw the artificial line around OAuth being
> “an authorization protocol” the better things will be.****
>  ****
> I like to say that they authors had it right when they named it “OAuth”
> and not “OAuthR” J****
>  ****
> -adam****
>  ****
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Tim Bray
> *Sent:* Tuesday, February 05, 2013 3:28 PM
> *To:* William Mills
> *Cc:* [email-masked] WG
> framework ?****
>  ****
> OIDC seems about the most plausible candidate for a “good general
> solution” that I’m aware of.   -T****
> On Tue, Feb 5, 2013 at 1:22 PM, William Mills <[email-masked]>
> wrote:****
> solution.****
>  ****
> -bill****
>  ****
> framework ?****
>  ****
> I agree that OAuth is not an *SSO* protocol.****
> On 2/5/13 3:36 PM, John Bradley wrote:****
>
> OAuth is an Authorization protocol as many of us have pointed out.****
>  ****
> The post is largely correct and based on one of mine.****
>  ****
> John B.****
>  ****
> On 2013-02-05, at 12:52 PM, Prabath Siriwardena <[email-masked]> wrote:*
> ***
>  ****
>
> FYI and for your comments..****
>  ****
>
> ****
>  ****
> Prabath****
>  ****
> Mobile : +94 71 809 6732 ****
> http://rampartfaq.com/****
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ****
>  ****
>
> _______________________________________________****
>
> OAuth mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ****
>
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>  ****
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en