Subject: [OAUTH-WG] Auth Server / Resource Server Coordination

From: Ofer Nave <[email-masked]>
Date: Tue, 13 Oct 2015 00:13:56 -0400

I know the OAuth 2.0 RFC doesn't specify any standards for coordination
between the Authorization Server and the Resource Server, as it's generally
assumed that both will be owned or operated by the same entity.

However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a
feature to make it easy for other API developers to delegate to me the
responsibility of handling the auth grant process and issuing access tokens.

It seems to me that a simple version of this could be easily done by:

1) Defining an Access Token format that contains within it everything a
Resource Server will need to validate it and determine the level of access
granted (list of scopes, expiration datetime, HMAC signature using a shared
secret).

2) Providing a means (basic web UI) for Resource Server owners to register
a set of scopes for their service, along with user-understandable
descriptions of each to display when they arrive at my Authorization
Endpoint.

While I've read the relevant RFCs, I'm new to the OAuth domain, and would
appreciate any feedback. Is this a stupid idea?  Is this a good idea, but
redundant with another standard I'm not aware of?

-ofer

---

From: Bill Mills <[email-masked]>
Date: Tue, 13 Oct 2015 04:20:48 +0000 (UTC)

You're generally right on track.  The RS needs to understand the token format and needs to trust the AS.  You bring in all the "hwo do 2 entities maintain a trust relationship in computing thing" here, because the RS needs to trust the AS.  You can use a JWT (a common choice) as your token format which makes that part fairly easy.  You do have decisions to make on whether you use symmetric crypto or PK there. 

     On Monday, October 12, 2015 9:14 PM, Ofer Nave <[email-masked]> wrote:

 I know the OAuth 2.0 RFC doesn't specify any standards for coordination between the Authorization Server and the Resource Server, as it's generally assumed that both will be owned or operated by the same entity.

However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a feature to make it easy for other API developers to delegate to me the responsibility of handling the auth grant process and issuing access tokens.

1) Defining an Access Token format that contains within it everything a Resource Server will need to validate it and determine the level of access granted (list of scopes, expiration datetime, HMAC signature using a shared secret).

2) Providing a means (basic web UI) for Resource Server owners to register a set of scopes for their service, along with user-understandable descriptions of each to display when they arrive at my Authorization Endpoint.

While I've read the relevant RFCs, I'm new to the OAuth domain, and would appreciate any feedback. Is this a stupid idea?  Is this a good idea, but redundant with another standard I'm not aware of?

-ofer

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

---

From: Jim Manico <[email-masked]>
Date: Tue, 13 Oct 2015 06:36:19 +0200

This seems like a reasonable approach. Isn't the whole idea of the auth server/resource server separation in OAuth 2.0 so that one auth server can govern multiple resource servers?

--
Jim Manico
@Manicode

> On Oct 13, 2015, at 6:13 AM, Ofer Nave <[email-masked]> wrote:
>

---

From: Ofer Nave <[email-masked]>
Date: Tue, 13 Oct 2015 00:37:43 -0400

> The RS needs to understand the token format and needs to trust the AS.

I'm not too concerned about that because the people who would be using my
service to handle auth for their API are mostly going to know me
personally.  (It's a community-specific service.)  And my code will be open
to them for review.

> You can use a JWT (a common choice) as your token format which makes that
part fairly easy.

I was wondering about that, actually, as I've never had to design a token
format.  I wasn't too worried, because it seems to me that even a simple,
obvious structure would be sufficient for the task (pick an object notation
like JSON or just a separator like pipe, put the fixed fields like
signature and expiration first, and then the rest are scope strings).
However, I agree it's generally wise to reuse existing, proven standards.

I learned about JWTs while studying OAuth2, and they do seem both
interesting an appropriate.  But they're also generalized, right?  As in,
not specific to OAuth 2.  Even this RFC about using JWT with OAuth2 doesn't
actually discuss, for example, how to encode a list of scopes within the
JWT:  https://tools.ietf.org/html/rfc7523

So, is there any kind of standard for an OAuth2 Access Token specifically
that addresses this need?  If not, I'll probably just build on top of JWT
since it's the closest.

> You do have decisions to make on whether you use symmetric crypto or PK
there.

That's another thing I was pondering -- simple shared secret, or require
generated a private/public key pair.

The asymetric form is a little more complicated in terms of the user
experience.  Is there a practical reason to prefer it?

-ofer

On Tue, Oct 13, 2015 at 12:20 AM, Bill Mills <[email-masked]> wrote:

> You're generally right on track.  The RS needs to understand the token
> format and needs to trust the AS.  You bring in all the "hwo do 2 entities
> maintain a trust relationship in computing thing" here, because the RS
> needs to trust the AS.  You can use a JWT (a common choice) as your token
> format which makes that part fairly easy.  You do have decisions to make on
> whether you use symmetric crypto or PK there.
>
>
>

---

From: Ofer Nave <[email-masked]>
Date: Tue, 13 Oct 2015 00:42:27 -0400

> Isn't the whole idea of the auth server/resource server separation in
OAuth 2.0 so that one auth server can govern multiple resource servers?

The spec certainly allows for that, but it stops short of:

1) Defining an Access Token structure that both parties can understand.
2) Any standards whatsoever about any other communication or coordination
between the AS and RS.

It's outside the scope of the spec, and so it falls to the implementer to
make those decisions.  This is my first attempt to do so.

The design I propose is very simple and yet seems to accomplish the goal
sufficiently.  The way OAuth2 is designed, authorization comes down to a
simple set of scope booleans, and that's very easy to model and delegate.
There's really no reason everyone should have to be reinventing this.  The
protocol for AS/RS coordination almost seems to write itself.  I'm
surprised an extension doesn't exist yet for this -- which is why I'm
asking for a sanity check, just in case I've missed something.

-ofer

On Tue, Oct 13, 2015 at 12:36 AM, Jim Manico <[email-masked]> wrote:

> This seems like a reasonable approach. Isn't the whole idea of the auth
> server/resource server separation in OAuth 2.0 so that one auth server can
> govern multiple resource servers?
>
> --
> Jim Manico
> @Manicode
>
> > 2) Providing a means (basic web UI) for Resource Server owners to
> register a set of scopes for their service, along with user-understandable
> > While I've read the relevant RFCs, I'm new to the OAuth domain, and
> would appreciate any feedback. Is this a stupid idea?  Is this a good idea,
> but redundant with another standard I'm not aware of?
> >
> > -ofer

---

From: Justin Richer <[email-masked]>
Date: Tue, 13 Oct 2015 04:36:13 -0400

I think what you’re talking about is reasonable, but I also think that you don’t need to invent anything. You’re right that these things aren’t defined in OAuth core itself, but instead they’re defined in companion specs. Most notably you have:

 - JWT (RFC7519): a structured token based on JSON and JOSE that lets you carry information inside the token itself. This can be signed and/or encrypted. The RS needs to understand the token format, but the client can still be oblivious to it and still function just fine. https://tools.ietf.org/html/rfc7519
 - Introspection (soon to be RFC7662, it’s in the final stage of editing as we speak): a simple protocol that allows an RS to query the AS with a token to see if it’s any good and what it’s good for. This returns a JSON document describing the token. https://tools.ietf.org/html/draft-ietf-oauth-introspection
 - UMA’s resource set registration (from Kantara, version 1.0.1 in final review right now): This is part of the User Managed Access (UMA) protocol and it lets an RS register a set of resources at the AS. This is very similar to what you’re describing below in terms of registering scopes for each resource server. https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg-v1_0_1.html

Combining these specs together you’ve got pretty much what you’re after, as best as I can tell. There are a number of implementations of all of these, including the project that I help run, MITREid Connect. https://github.com/mitreid-connect/ Our server issues signed JWTs, provides token introspection, and lets resource server owners register their scopes to expose to users through a simple web UI. 

 — Justin

> On Oct 13, 2015, at 12:13 AM, Ofer Nave <[email-masked]> wrote:
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 13 Oct 2015 11:40:04 +0300

> experience.  Is there a practical reason to prefer it?

If the AS and the Resource Servers (RS) share a secret, there is a risk
of an RS impersonating authorised clients by creating valid tokens to
access other RSs.

You may prevent this by making sure every RS gets its own secret, but in
that case you cannot issue tokens with multiple RS audiences.

With asymmetric keys you won't have these problems. The RS would only
need to have a copy of the public AS key to verify the tokens.

Vladimir

-- 
Vladimir Dzhuvinov

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 13 Oct 2015 09:10:28 +0000

> granted (list of scopes, expiration datetime, HMAC signature using a shared

Either that (and I'd use JWT then, as already proposed) or have resource
servers introspect tokens <
https://tools.ietf.org/html/draft-ietf-oauth-introspection-11> (the latter
doesn't preclude the former, but the format of the token is then just an
implementation detail of the AS that the RS doesn't need to know).
One advantage of requiring introspection is the easy support of revocation
without having to create a specific API to check whether a token is
revoked: you just introspect the token and directly know whether the token
is valid or not, and if it's valid you get its details (and have the RS
cache the response for a few seconds/minutes to avoid overloading the
introspection endpoint). That being said, RS knowing the tokens are JWTs
allows them to reject invalid tokens (expired, invalid signature,
unexpected issuer, etc.) without the need to check for revocation at the AS.

> descriptions of each to display when they arrive at my Authorization

Either a Web UI, or an API <
https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06> (I'm not
a fan of this draft, and it incidentally violates IETF's BCP190
https://tools.ietf.org/html/bcp190, but I think it's a good source of
inspiration)

---

From: Ofer Nave <[email-masked]>
Date: Tue, 13 Oct 2015 09:40:08 -0400

> You’re right that these things aren’t defined in OAuth core itself, but
instead they’re defined in companion specs.

Awesome!  That's what I was hoping.

FYI - Up till now, I had only encountered the following relevant specs:

https://tools.ietf.org/html/rfc6749 — The OAuth 2.0 Authorization Framework
https://tools.ietf.org/html/rfc6750 — The OAuth 2.0 Authorization
Framework: Bearer Token Usage
https://tools.ietf.org/html/rfc6819 — OAuth 2.0 Threat Model and Security
Considerations
https://tools.ietf.org/html/rfc7009 — OAuth 2.0 Token Revocation
http://openid.net/specs/openid-connect-core-1_0.html
http://openid.net/specs/openid-connect-registration-1_0.html
http://openid.net/specs/openid-connect-discovery-1_0.html
https://tools.ietf.org/html/rfc7515 — JSON Web Signature (JWS)
https://tools.ietf.org/html/rfc7516 — JSON Web Encryption (JWE)
https://tools.ietf.org/html/rfc7519 — JSON Web Token (JWT)
https://tools.ietf.org/html/rfc7523 — JSON Web Token (JWT) Profile for
OAuth 2.0 Client Authentication and Authorization Grants
https://tools.ietf.org/html/rfc7033 — WebFinger
https://tools.ietf.org/html/rfc2617 — HTTP Authentication: Basic and Digest
Access Authentication

I'll add the two you mentioned to the list.

Any more useful specs I'm missing?  :)

-ofer

On Tue, Oct 13, 2015 at 4:36 AM, Justin Richer <[email-masked]> wrote:

> I think what you’re talking about is reasonable, but I also think that you
> don’t need to invent anything. You’re right that these things aren’t
> defined in OAuth core itself, but instead they’re defined in companion
> specs. Most notably you have:
>
>
>  - JWT (RFC7519): a structured token based on JSON and JOSE that lets you
> carry information inside the token itself. This can be signed and/or
> encrypted. The RS needs to understand the token format, but the client can
> still be oblivious to it and still function just fine.
> https://tools.ietf.org/html/rfc7519
>  - Introspection (soon to be RFC7662, it’s in the final stage of editing
> as we speak): a simple protocol that allows an RS to query the AS with a
> token to see if it’s any good and what it’s good for. This returns a JSON
> document describing the token.
> https://tools.ietf.org/html/draft-ietf-oauth-introspection
>  - UMA’s resource set registration (from Kantara, version 1.0.1 in final
> review right now): This is part of the User Managed Access (UMA) protocol
> and it lets an RS register a set of resources at the AS. This is very
> similar to what you’re describing below in terms of registering scopes for
> each resource server.
> https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg-v1_0_1.html
>
>
> Combining these specs together you’ve got pretty much what you’re after,
> as best as I can tell. There are a number of implementations of all of
> these, including the project that I help run, MITREid Connect.
> https://github.com/mitreid-connect/ Our server issues signed JWTs,
> provides token introspection, and lets resource server owners register
> their scopes to expose to users through a simple web UI.
>
>
>  — Justin
>
>

---

From: Ofer Nave <[email-masked]>
Date: Tue, 13 Oct 2015 09:42:30 -0400

That's an excellent point I had considered.

-ofer

On Tue, Oct 13, 2015 at 4:40 AM, Vladimir Dzhuvinov <[email-masked]
> wrote:

---

From: Ofer Nave <[email-masked]>
Date: Tue, 13 Oct 2015 09:48:46 -0400

> One advantage of requiring introspection is the easy support of
revocation without having to create a specific API to check whether a token
is revoked: you just introspect the token and directly know whether the
token is valid or not, and if it's valid you get its details (and have the
RS cache the response for a few seconds/minutes to avoid overloading the
introspection endpoint). That being said, RS knowing the tokens are JWTs
allows them to reject invalid tokens (expired, invalid signature,
unexpected issuer, etc.) without the need to check for revocation at the AS.

It did occur to me that if I make the AT self-contained, then RO-initiated
scope revocation wouldn't take affect until the next time a new AT is
requested using the RT (when the old AT expires), which I was going to set
to 30m to prevent swamping the token endpoint (which would happen if RS's
had to call me to validate the AT every time).

Now that I know about these extra specs, I'm tempted to implement both
(self-contained ATs *and* an introspection endpoint), and see what the
adopters decide to do.

What don't you like about it?  And can I mitigate the factors you're
concerned about in my decision-making process without violating the draft
spec?

-ofer

On Tue, Oct 13, 2015 at 5:10 AM, Thomas Broyer <[email-masked]> wrote:

> https://tools.ietf.org/html/draft-ietf-oauth-introspection-11> (the
> latter doesn't preclude the former, but the format of the token is then
> just an implementation detail of the AS that the RS doesn't need to know).
> https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06> (I'm
> not a fan of this draft, and it incidentally violates IETF's BCP190

---

From: Ofer Nave <[email-masked]>
Date: Tue, 13 Oct 2015 09:50:40 -0400

BTW -- I'd like to say I'm very pleasantly surprised by the quantity,
quality, and speediness of all your responses.  I assumed this list was
low-attention based on glancing at the archives, but maybe that's just
because ya'll already know everything you need to know and noobs are rare.
:)

-ofer

---

From: Bill Mills <[email-masked]>
Date: Tue, 13 Oct 2015 14:43:48 +0000 (UTC)

Centralizing the user auth yes, it doesn't even have to be multiple types of RS for this to win.  It reduces your attack surface and allows your auth stack to be separate from your app stack are two of the good things.  Auth is a specialized thing and hard to do right, and pulling it down to a much smaller pool of machines than your main application servers lets you more easily see and deal with abuse. 

     On Monday, October 12, 2015 9:36 PM, Jim Manico <[email-masked]> wrote:

--
Jim Manico
@Manicode

---

From: Eve Maler <[email-masked]>
Date: Tue, 13 Oct 2015 09:04:27 -0700

Hi Thomas— The UMA Work Group that produced the “RSR” (OAuth Resource Set Registration) spec has an outstanding issue to fix the BCP190 issue that you point out. Since it’s a backwards-incompatible change, and we are taking a semantic versioning approach, we need to plot it out appropriately. We certainly welcome other comments. The V1.0.1 draft spec is currently in a public review period <http://kantarainitiative.org/confluence/display/uma/Home>, closing Nov 2.

(Small tweak to Justin’s note: This spec is meant not to be specific to UMA, but rather to be potentially usable for “vanilla” OAuth and OpenID Connect as well.)

	Eve

> On 13 Oct 2015, at 2:10 AM, Thomas Broyer <[email-masked]> wrote:
> 
> 
> 
> On Tue, Oct 13, 2015 at 6:14 AM Ofer Nave <[email-masked] <mailto:[email-masked]>> wrote:
> Either that (and I'd use JWT then, as already proposed) or have resource servers introspect tokens <https://tools.ietf.org/html/draft-ietf-oauth-introspection-11 <https://tools.ietf.org/html/draft-ietf-oauth-introspection-11>> (the latter doesn't preclude the former, but the format of the token is then just an implementation detail of the AS that the RS doesn't need to know).
> One advantage of requiring introspection is the easy support of revocation without having to create a specific API to check whether a token is revoked: you just introspect the token and directly know whether the token is valid or not, and if it's valid you get its details (and have the RS cache the response for a few seconds/minutes to avoid overloading the introspection endpoint). That being said, RS knowing the tokens are JWTs allows them to reject invalid tokens (expired, invalid signature, unexpected issuer, etc.) without the need to check for revocation at the AS.
>  
> Either a Web UI, or an API <https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06 <https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06>> (I'm not a fan of this draft, and it incidentally violates IETF's BCP190 https://tools.ietf.org/html/bcp190 <https://tools.ietf.org/html/bcp190>, but I think it's a good source of inspiration)

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: [email-masked]

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 21 Oct 2015 14:06:12 +0100

Hi

I can not subscribe to an OIDC spec list, had some earlier questions not 
flowing to the list and given I'm not sure this question is irrelevant 
for this group (OIDC IDP is an OAuth2 server), I'm posting it here. If 
you'd like me to re-post to the OIDC list then let me know 
please...Sorry for a noise, just in case :-)

So, all the flows in OIDC Core have this section:

http://openid.net/specs/openid-connect-core-1_0.html#Consent
http://openid.net/specs/openid-connect-core-1_0.html#ImplicitConsent
http://openid.net/specs/openid-connect-core-1_0.html#HybridConsent

This is pure OAuth2 still.

What I do not understand, if the response_type is 'id_token' and the 
requested scope is 'openid' only,

http://openid.net/specs/openid-connect-core-1_0.html#Authentication

then what is a consent screen really about ?

If the response_code is 'id_token' then a user has already given the 
implicit authorization after visiting a client application web page and 
clicking "Sign In With Google"/etc, and signing in into OIDC IDP. I 
thought this is what "openid" alone is all about.

Can someone clarify please if it is reasonable to skip challenging a 
user with a consent screen in this case.

Thanks, Sergey

---

From: Justin Richer <[email-masked]>
Date: Wed, 21 Oct 2015 09:37:48 -0400

You're assuming that the user actually took an action to get to that 
page. It's trivial for a website, any website, to craft a URL and 
redirect a user to the IdP. I could give you a link here in this email 
hidden behind a URL shortener or some other redirector. It would be very 
bad practice to release identity information to any site that was 
capable of doing this, and it would be likewise bad to assume 
authorization just because the user showed up at a URL. The ID token 
contains information like a unique identifier and potentially other 
claims (google puts in email addresses, for instance).

The common practice, codified in both OAuth2 and OIDC, is "Trust On 
First Use", or TOFU. If it's a new situation (new client/RP, new scopes, 
something else you're not sure about), you ask the user. Then you 
(optionally) save that for next time, so if the same situation arises, 
you already have the user's decision and you don't need to prompt them. 
This can be further augmented by whitelisting trusted sites, where the 
IdP/AS is making the authorization decision and not the user.

Hope this helps,
  -- Justin

On 10/21/2015 9:06 AM, Sergey Beryozkin wrote:
> Hi
>
> I can not subscribe to an OIDC spec list, had some earlier questions 
> not flowing to the list and given I'm not sure this question is 
> irrelevant for this group (OIDC IDP is an OAuth2 server), I'm posting 
> it here. If you'd like me to re-post to the OIDC list then let me know 
> implicit authorization after visiting a client application web page 
> and clicking "Sign In With Google"/etc, and signing in into OIDC IDP. 
> I thought this is what "openid" alone is all about.
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 21 Oct 2015 15:01:41 +0100

Hi Justin

It helps, many thanks. I understand why 'MUST' is there now...

Cheers, Sergey

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/