Subject: [OAUTH-WG] AS Discovery in Distributed Draft

From: Justin P Richer <[email-masked]>
Date: Tue, 6 Nov 2018 05:19:18 +0000

In the meeting tonight I brought up a response to the question of whether to have full URL or plain issuer for the auth server in the RS response’s header. My suggestion was that we have two different parameters to the header to represent the AS: one of them being the full URL (as_uri) and one of them being the issuer to be constructed somehow (as_issuer). I ran into a similar problem on a system that I built last year where all of our servers had discovery documents but not all of them were easily constructed from an issuer style URL (using OIDC patterns anyway). So we solved it by having two different variables. If the full URL was set, we used that; if it wasn’t, we tried the issuer; if neither was set we didn’t do any discovery.

I’m sensitive to Torsten’s concerns about complexity, but I think this is a simple and deterministic solution that sidesteps much of the issue. No pun intended.

— Justin

---

From: David Waite <[email-masked]>
Date: Mon, 5 Nov 2018 22:35:39 -0700

Is there a need for a client to understand the identity of an authorization server?

This would seem to mean that the token or authorization endpoint would need to be that identity, rather than the issuer (since now the metadata might not be from an authoritative location)

-DW

> On Nov 5, 2018, at 10:19 PM, Justin P Richer <[email-masked]> wrote:
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin P Richer <[email-masked]>
Date: Tue, 6 Nov 2018 05:57:33 +0000

The need is in the distributed OAuth draft, which has more detail of its use case. The problem with using either the token or authorization endpoint as the sole identity of the auth server is that Oauth doesn’t stick to just one of them and there’s no solid way to tie them together apart from AS discovery.

— Justin

On Nov 6, 2018, at 12:35 AM, David Waite <[email-masked]<mailto:[email-masked]>> wrote:

-DW

On Nov 5, 2018, at 10:19 PM, Justin P Richer <[email-masked]<mailto:[email-masked]>> wrote:

— Justin

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

---

From: George Fletcher <[email-masked]>
Date: Wed, 7 Nov 2018 16:08:24 -0500

Related to this discussion of AS discovery... what is the value of using 
the Link response header over just returning the variables in the 
WWW-Authenticate header? Could we not use...

WWW-Authenticate: OAuth realm="example_realm", scope="example_scope", 
error="invalid_token", rs_uri="https://api.example.com/resource", 
as_uri="https://as1.example.com,https://as2.example.com"

Thanks,
George

On 11/6/18 12:19 AM, Justin P Richer wrote:
> In the meeting tonight I brought up a response to the question of 
> whether to have full URL or plain issuer for the auth server in the RS 
> response’s header. My suggestion was that we have two different 
> parameters to the header to represent the AS: one of them being the 
> full URL (as_uri) and one of them being the issuer to be constructed 
> somehow (as_issuer). I ran into a similar problem on a system that I 
> built last year where all of our servers had discovery documents but 
> not all of them were easily constructed from an issuer style URL 
> (using OIDC patterns anyway). So we solved it by having two different 
> variables. If the full URL was set, we used that; if it wasn’t, we 
> tried the issuer; if neither was set we didn’t do any discovery.
>
> I’m sensitive to Torsten’s concerns about complexity, but I think this 
> is a simple and deterministic solution that sidesteps much of the 
> issue. No pun intended.
>
> — Justin
>
>
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 7 Nov 2018 13:28:03 -0800

I’m seeing broader need for discovery of OAuth infrastructure for APIs in general now that APIs are being deployed by many parties:
* based on a standard (e.g. SCIM, IMAP, SMTP)
* Implemented in open source and deployed by many (e.g. K8S and its various components).
* Services like streaming (Kakfa) 
* Serverless/microservices APIs

I agree, that having some process where the RS can indicate to a client where to go do discovery would be helpful.  The issue is somewhat complex and we have talked about some of this before. For example, an RS may have multiple AS’s it accepts tokens from. Does the RS indicate many or specific discovery endpoint that may or may not involve registration (in order to determine the appropriate AS)?  How is the metadata secured?  How do we ensure we haven’t opened up an automated attack point (e.g. a MITM’d RS gives a client false discovery information).

Phil

Oracle Corporation, Cloud Security and Identity Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Nov 7, 2018, at 1:08 PM, George Fletcher <gffletch=[email-masked]> wrote:
> 
> Related to this discussion of AS discovery... what is the value of using the Link response header over just returning the variables in the WWW-Authenticate header? Could we not use...
> 
> WWW-Authenticate: OAuth realm="example_realm", scope="example_scope", error="invalid_token", rs_uri="https://api.example.com/resource" <https://api.example.com/resource>, as_uri="https://as1.example.com,https://as2.example.com" <https://as1.example.com,https//as2.example.com>
> 
> Thanks,
> George
> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 8 Nov 2018 17:13:35 +0700

Phil, would you clarify what you are suggesting? I'm unclear if you are
disagreeing with George or not.

On Thu, Nov 8, 2018 at 4:28 AM Phil Hunt <[email-masked]> wrote:

> I’m seeing broader need for discovery of OAuth infrastructure for APIs in
> general now that APIs are being deployed by many parties:
> I agree, that having some process where the RS can indicate to a client
> where to go do discovery would be helpful.  The issue is somewhat complex
> and we have talked about some of this before. For example, an RS may have
> multiple AS’s it accepts tokens from. Does the RS indicate many or specific
> discovery endpoint that may or may not involve registration (in order to
> determine the appropriate AS)?  How is the metadata secured?  How do we
> ensure we haven’t opened up an automated attack point (e.g. a MITM’d RS
> gives a client false discovery information).
>
> Phil
>
> www.independentid.com
> [email-masked]
> On Nov 7, 2018, at 1:08 PM, George Fletcher <
> gffletch=[email-masked]> wrote:
>
> error="invalid_token", rs_uri="https://api.example.com/resource"
> <https://api.example.com/resource>, as_uri=
> "https://as1.example.com,https://as2.example.com"
> <https://as1.example.com,https//as2.example.com>
>
> Thanks,
> George
>
> In the meeting tonight I brought up a response to the question of whether
> to have full URL or plain issuer for the auth server in the RS response’s
> header. My suggestion was that we have two different parameters to the
> header to represent the AS: one of them being the full URL (as_uri) and one
> of them being the issuer to be constructed somehow (as_issuer). I ran into
> a similar problem on a system that I built last year where all of our
> servers had discovery documents but not all of them were easily constructed
> from an issuer style URL (using OIDC patterns anyway). So we solved it by
> having two different variables. If the full URL was set, we used that; if
> it wasn’t, we tried the issuer; if neither was set we didn’t do any
> discovery.
>
> I’m sensitive to Torsten’s concerns about complexity, but I think this is
> a simple and deterministic solution that sidesteps much of the issue. No
> pun intended.
>
> — Justin
>
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 8 Nov 2018 17:16:00 +0700

George: in the WG meeting we discussed this topic of where to put the
discovery information. No one at the meeting advocated for using Link
response (Nat was the one who was advocating for this). Many others
preferred using the www-authenticate header similar to how you propose.

On Thu, Nov 8, 2018 at 4:08 AM George Fletcher <gffletch=
[email-masked]> wrote:

> <https://as1.example.com,https://as2.example.com>
>
> Thanks,
> George
>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 8 Nov 2018 17:17:35 +0700

There is a requirement in Distributed OAuth for the client to locate one or
more AS metadata files for a given resource.

On Tue, Nov 6, 2018 at 12:35 PM David Waite <[email-masked]>
wrote:

> This would seem to mean that the token or authorization endpoint would
> need to be that identity, rather than the issuer (since now the metadata
> might not be from an authoritative location)
>
> -DW
>

---

From: George Fletcher <[email-masked]>
Date: Thu, 8 Nov 2018 10:11:30 -0500

Cool! Sorry I couldn't make the meeting. One benefit of using 
WWW-Authenticate is that UMA has basically the same discovery logic 
(from RS to AS) and uses the WWW-Authenticate header. Keeping this 
discovery method the same (since UMA is just a profile of OAuth anyway) 
will help all developers.

On 11/8/18 5:16 AM, Dick Hardt wrote:
> On Thu, Nov 8, 2018 at 4:08 AM George Fletcher 
> <gffletch=[email-masked] <mailto:[email-masked]..org>> 
> wrote:
>
>     Related to this discussion of AS discovery... what is the value of
>     using the Link response header over just returning the variables
>     in the WWW-Authenticate header? Could we not use...
>
>     WWW-Authenticate: OAuth realm="example_realm",
>     scope="example_scope", error="invalid_token",
>     rs_uri="https://api.example.com/resource"
>     <https://api.example.com/resource>,
>>     whether to have full URL or plain issuer for the auth server in
>>     the RS response’s header. My suggestion was that we have two
>>     different parameters to the header to represent the AS: one of
>>     them being the full URL (as_uri) and one of them being the issuer
>>     to be constructed somehow (as_issuer). I ran into a similar
>>     problem on a system that I built last year where all of our
>>     servers had discovery documents but not all of them were easily
>>     constructed from an issuer style URL (using OIDC patterns
>>     anyway). So we solved it by having two different variables. If
>>     the full URL was set, we used that; if it wasn’t, we tried the
>>     issuer; if neither was set we didn’t do any discovery.
>>
>>     I’m sensitive to Torsten’s concerns about complexity, but I think
>>     this is a simple and deterministic solution that sidesteps much
>>     of the issue. No pun intended.
>>
>>     — Justin
>>
>>
>>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 8 Nov 2018 09:08:20 -0800

Dick, 

I was generally agreeing with George and stating I think we have an emerging *general* OAuth2 discovery problem emerging.

Phil

> On Nov 8, 2018, at 7:11 AM, George Fletcher <gffletch=[email-masked]> wrote:
> 
> Cool! Sorry I couldn't make the meeting. One benefit of using WWW-Authenticate is that UMA has basically the same discovery logic (from RS to AS) and uses the WWW-Authenticate header. Keeping this discovery method the same (since UMA is just a profile of OAuth anyway) will help all developers.
> 
>> George: in the WG meeting we discussed this topic of where to put the discovery information. No one at the meeting advocated for using Link response (Nat was the one who was advocating for this). Many others preferred using the www-authenticate header similar to how you propose.
>> 
>> On Thu, Nov 8, 2018 at 4:08 AM George Fletcher <gffletch=[email-masked] <mailto:[email-masked]..org>> wrote:

---

From: n-sakimura <[email-masked]>
Date: Fri, 16 Nov 2018 07:27:24 +0000

Hmmm. But the Link-header is the generalized discovery method which is pretty widely used outside of OAuth community with the added benefit of being able to find things without linking to authentication.

From: OAuth <[email-masked]> On Behalf Of George Fletcher
Sent: Friday, November 09, 2018 12:12 AM
To: Dick Hardt <[email-masked]>; gffletch=[email-masked]
Cc: [email-masked]
Subject: Re: [OAUTH-WG] AS Discovery in Distributed Draft

On Thu, Nov 8, 2018 at 4:08 AM George Fletcher <gffletch=[email-masked]<mailto:[email-masked]..org>> wrote:
Related to this discussion of AS discovery... what is the value of using the Link response header over just returning the variables in the WWW-Authenticate header? Could we not use...

WWW-Authenticate: OAuth realm="example_realm", scope="example_scope", error="invalid_token", rs_uri="https://api.example.com/resource"<https://api.example.com/resource>, as_uri="https://as1.example.com,https://as2.example.com"<https://as1.example.com,https:/as2.example.com>

Thanks,
George

— Justin

OAuth mailing list

OAuth mailing list

---

From: Dick Hardt <[email-masked]>
Date: Fri, 16 Nov 2018 17:02:39 -0800

Hi Nat

Currently, you are the only one actively taking the position of
Link-header. Perhaps you can educate the broader WG on the value of using
Link-header over WWW-Authenticate?

On Thu, Nov 15, 2018 at 11:27 PM n-sakimura <[email-masked]> wrote:

> Hmmm. But the Link-header is the generalized discovery method which is
> pretty widely used outside of OAuth community with the added benefit of
> being able to find things without linking to authentication.
>
>
>
> *From:* OAuth <[email-masked]> *On Behalf Of *George Fletcher
> *Sent:* Friday, November 09, 2018 12:12 AM
> *To:* Dick Hardt <[email-masked]>; gffletch=[email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] AS Discovery in Distributed Draft
>
>
>
> WWW-Authenticate is that UMA has basically the same discovery logic (from
> RS to AS) and uses the WWW-Authenticate header. Keeping this discovery
> method the same (since UMA is just a profile of OAuth anyway) will help all
> developers.
>
> [email-masked] <[email-masked]..org>> wrote:
>
> <https://as1.example.com,https:/as2.example.com>
>
> Thanks,
> George
>