Re: [OAUTH-WG] New OAuth I-D: Incremental Auth

[Sergey Beryozkin]

Hi
On 07/07/17 18:56, William Denniss wrote:

What you describe is incremental auth.

Thanks... FYI, I thought of doing some work around it after browsing 
through the Google docs; the line about the "asking to approve the 
purchase of the kitchen sink at the authentication time is a death of 
the modern web" (or something similar that I read on this list) was even 
more convincing :-)


Aside: Do you return the "scope" in the token response as required when 
the scope in the response is not identical to the request (§ 5.1 
<https://tools.ietf.org/html/rfc6749#section-5.1>, parameter: scope)?


Yes, the token service is doing it by default for all the returned 
access tokens


My only question is: does the client expect this?  The spec talks about 
the authorization server *reducing* scope in a few places (in § 3.3 
<https://tools.ietf.org/html/rfc6749#section-3.3>, "The authorization 
server MAY fully or partially ignore the scope requested by the client" 
and § 10.3 <https://tools.ietf.org/html/rfc6749#section-10.3> "The 
authorization server SHOULD take the client identity into account when 
choosing how to honor the requested scope and MAY issue an access token 
with less rights than requested.").  It never talks about *increasing* 
scope (other than it can't be done during refresh).


So I think some normative language around the potential to increase the 
scope of the request for confidential clients (in either the way you 
describe, or the way I described in the draft) is warranted.


Open question: should we require an indication from the client if they 
*want* the scope increase? That's what include_granted_scopes was 
designed to do. To allow clients to specify if this is behavior they desire.
Right, I see how a proposed "include_granted_scopes" can make it non 
ambiguous



The more innovative part of the spec I think is the public (native app) 
client incremental auth – as native apps cannot use the methods you 
discuss, or the ones Google has supported for a while for confidential 
clients. That said, if we write this – I think we may as well formally 
document approaches for confidential clients too.




thanks, Sergey


On Fri, Jul 7, 2017 at 9:24 AM, Sergey Beryozkin <mailto:sberyoz...@gmail.com>> wrote:


Hi

Re the confidential client: let me explain please how we
experimented with this feature when the code flow is used.

1. Client requests a scope 'a' for a given User, it gets approved by
the user, the clients gets a code and exchanges it for a token.

2. At some later stage Client requests a scope 'b' for the same user
and if an access token for a given Client + User combination exists
and the incremental authorization is supported (we use a different
term for now) than the service finds out from this token that 'a'
has already been approved and offers a consent screen where a user
sees 'a' being selected and needs to approve 'b'.

3. User approves 'b'. The client gets a new code back and exchanges
it for a new token which now has "a" and "b".

At this point a client has 2 tokens, one with the "a" scope and
another with the "a" and "b" scopes and the assumption was that the
client would itself remove the now redundant token with the scope
"a" only.

I've just updated the code for the service itself do it on the
client's behalf, optionally remove the scope "a" token so that the
client can simply replace a reference to its scope "a" token with
the new one (scopes "a" and "b") it will get after exchanging a code
grant.

Is it an incremental authorization or something else completely :-) ?

One obvious difference, apart from the lower level implementation
details, is that it is not a client which requests to include the
already authorized scopes but the service does it itself if the
configuration allowing for it is enabled

Thanks, Sergey






On 05/07/17 18:17, William Denniss wrote:

Earlier this week I submitted the following I-D:
https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth 
<https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth>

The topic is incremental authentication (or incremental auth for
short).  Incremental auth is used to enable clients to request
just the scopes they need when they need them – rather than all
upfront – while still only a maintaining a single authorization
grant.

The I-D details two techniques used at Google, one that has been
used for a while in confidential clients, and one that we
launched recently as a new solution to deliver incremental auth
for publi

Re: [OAUTH-WG] New OAuth I-D: Incremental Auth

[Sergey Beryozkin]

Hi

Re the confidential client: let me explain please how we experimented 
with this feature when the code flow is used.


1. Client requests a scope 'a' for a given User, it gets approved by the 
user, the clients gets a code and exchanges it for a token.


2. At some later stage Client requests a scope 'b' for the same user and 
if an access token for a given Client + User combination exists and the 
incremental authorization is supported (we use a different term for now) 
than the service finds out from this token that 'a' has already been 
approved and offers a consent screen where a user sees 'a' being 
selected and needs to approve 'b'.


3. User approves 'b'. The client gets a new code back and exchanges it 
for a new token which now has "a" and "b".


At this point a client has 2 tokens, one with the "a" scope and another 
with the "a" and "b" scopes and the assumption was that the client would 
itself remove the now redundant token with the scope "a" only.


I've just updated the code for the service itself do it on the client's 
behalf, optionally remove the scope "a" token so that the client can 
simply replace a reference to its scope "a" token with the new one 
(scopes "a" and "b") it will get after exchanging a code grant.


Is it an incremental authorization or something else completely :-) ?

One obvious difference, apart from the lower level implementation 
details, is that it is not a client which requests to include the 
already authorized scopes but the service does it itself if the 
configuration allowing for it is enabled


Thanks, Sergey





On 05/07/17 18:17, William Denniss wrote:
Earlier this week I submitted the following I-D: 
https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth


The topic is incremental authentication (or incremental auth for 
short).  Incremental auth is used to enable clients to request just the 
scopes they need when they need them – rather than all upfront – while 
still only a maintaining a single authorization grant.


The I-D details two techniques used at Google, one that has been used 
for a while in confidential clients, and one that we launched recently 
as a new solution to deliver incremental auth for public clients.


I look forward to discussing this proposal with the working group. I 
plan to present this draft at IETF99, hope you can be there or watching 
the livestream!


I plan to ask for a call for adoption after that presentation. If you're 
interested in this topic I'd encourage you to read the draft (it's 
fairly concise!).


Best,
William



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-mtls-00.txt

[Sergey Beryozkin]

Hi All

I'm starting really believing now doing OAuth2 is as simple as spotting 
a difference between 'S' and 's' :-)


Thanks, Sergey
On 07/04/17 17:28, Steve Hutchinson wrote:

Every time I think I couldn't be more impressed with the people who do
actual standards work, someone raises the bar.

Thanks Sergey!

Hutch


On Fri, Apr 7, 2017 at 10:42 AM Sergey Beryozkin mailto:sberyoz...@gmail.com>> wrote:

Hi John

I spotted it probably after the 10th iteration :-)

Cheers, Sergey
On 07/04/17 14:54, John Bradley wrote:
> It was a test to see who was really reading it:)
>
    > On Fri, Apr 7, 2017 at 1:58 PM, Sergey Beryozkin
mailto:sberyoz...@gmail.com>
> <mailto:sberyoz...@gmail.com <mailto:sberyoz...@gmail.com>>> wrote:
>
> Hi Brian
>
> Thanks, a minor typo in the example,
> "x5t#s256" as opposed to "x5t#S256"
>
> (sorry if it was already reported, might've missed it)
>
> Cheers, Sergey
> On 30/03/17 22:15, Brian Campbell wrote:
>
> This document, which I hope to present and discuss briefly at
> tomorrow's
> meeting, replaces (but keeps the feature) the Mutual TLS
> Authentication
> for OAuth Clients
>
 <https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00
>
 <https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00>>
> that was published leading up to the Seoul meeting
>
 <https://www.ietf.org/mail-archive/web/oauth/current/msg16704.html
>
 <https://www.ietf.org/mail-archive/web/oauth/current/msg16704.html>>
> and
> adds mutual TLS sender constrained access to OAuth protected
> resources.
> The concept for the latter was largely derived from one of the
> options
> in the JPOP draft
> <https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04
> <https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04>>. I
> apologize
> for the 11th hour publication but hope some folks will have a
> chance to
> read it.
>
> -- Forwarded message --
> From: ** mailto:internet-dra...@ietf.org>
> <mailto:internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>>
> <mailto:internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org> <mailto:internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>>>>
> Date: Thu, Mar 30, 2017 at 3:49 PM
> Subject: New Version Notification for
> draft-campbell-oauth-mtls-00.txt
> To: Brian Campbell mailto:brian.d.campb...@gmail.com>
> <mailto:brian.d.campb...@gmail.com
<mailto:brian.d.campb...@gmail.com>>
> <mailto:brian.d.campb...@gmail.com
<mailto:brian.d.campb...@gmail.com>
> <mailto:brian.d.campb...@gmail.com
<mailto:brian.d.campb...@gmail.com>>>>, Nat Sakimura
> mailto:n-sakim...@nri.co.jp>
<mailto:n-sakim...@nri.co.jp <mailto:n-sakim...@nri.co.jp>>
> <mailto:n-sakim...@nri.co.jp <mailto:n-sakim...@nri.co.jp>
<mailto:n-sakim...@nri.co.jp <mailto:n-sakim...@nri.co.jp>>>>,
> Torsten Lodderstedt
> mailto:tors...@lodderstedt.net>
<mailto:tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>>
> <mailto:tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net>
> <mailto:tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net>>>>, John Bradley
> mailto:ve7...@ve7jtb.com>
<mailto:ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>>
> <mailto:ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>
<mailto:ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>>>>
>
>
>
> A new version of I-D, draft-campbell-oauth-mtls-00.txt
> has been successfully submitted by Brian Campbell and
posted to the
> IETF repository.
>
> Name:   draft-campbell-oauth-mtls
> Revision:   00
> Title:  Mutual TLS Profiles for OAuth Clients
> Document date:  2017-03-30
> Group:  Individual Submission
> Pages:  10
> URL:
>
 https://www.ietf.org/internet-drafts/draf

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-mtls-00.txt

[Sergey Beryozkin]

Hi John

I spotted it probably after the 10th iteration :-)

Cheers, Sergey
On 07/04/17 14:54, John Bradley wrote:

It was a test to see who was really reading it:)

On Fri, Apr 7, 2017 at 1:58 PM, Sergey Beryozkin mailto:sberyoz...@gmail.com>> wrote:

Hi Brian

Thanks, a minor typo in the example,
"x5t#s256" as opposed to "x5t#S256"

(sorry if it was already reported, might've missed it)

Cheers, Sergey
On 30/03/17 22:15, Brian Campbell wrote:

This document, which I hope to present and discuss briefly at
tomorrow's
meeting, replaces (but keeps the feature) the Mutual TLS
Authentication
for OAuth Clients
<https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00
<https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00>>
that was published leading up to the Seoul meeting
<https://www.ietf.org/mail-archive/web/oauth/current/msg16704.html
<https://www.ietf.org/mail-archive/web/oauth/current/msg16704.html>>
and
adds mutual TLS sender constrained access to OAuth protected
resources.
The concept for the latter was largely derived from one of the
options
in the JPOP draft
<https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04
<https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04>>. I
apologize
for the 11th hour publication but hope some folks will have a
chance to
read it.

-- Forwarded message --
From: ** mailto:internet-dra...@ietf.org>
<mailto:internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>>>
Date: Thu, Mar 30, 2017 at 3:49 PM
Subject: New Version Notification for
draft-campbell-oauth-mtls-00.txt
To: Brian Campbell mailto:brian.d.campb...@gmail.com>
<mailto:brian.d.campb...@gmail.com
<mailto:brian.d.campb...@gmail.com>>>, Nat Sakimura
mailto:n-sakim...@nri.co.jp>
<mailto:n-sakim...@nri.co.jp <mailto:n-sakim...@nri.co.jp>>>,
Torsten Lodderstedt
mailto:tors...@lodderstedt.net>
<mailto:tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net>>>, John Bradley
mailto:ve7...@ve7jtb.com>
<mailto:ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>>>



A new version of I-D, draft-campbell-oauth-mtls-00.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:   draft-campbell-oauth-mtls
Revision:   00
Title:  Mutual TLS Profiles for OAuth Clients
Document date:  2017-03-30
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt
<https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt>
<https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt
<https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt>>
Status:
 https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/
<https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/>
<https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/
<https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/>>
Htmlized:
 https://tools.ietf.org/html/draft-campbell-oauth-mtls-00
<https://tools.ietf.org/html/draft-campbell-oauth-mtls-00>
<https://tools.ietf.org/html/draft-campbell-oauth-mtls-00
<https://tools.ietf.org/html/draft-campbell-oauth-mtls-00>>
Htmlized:
 https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00
<https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00>
<https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00
<https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00>>


Abstract:
   This document describes Transport Layer Security (TLS) mutual
   authentication using X.509 certificates as a mechanism for
both OAuth
   client authentication to the token endpoint as well as for sender
   constrained access to OAuth protected resources.




Please note that it may take a couple of minutes from the time
of submission
until the htmlized version and diff are available at
tools.ietf.org <http://tools.ietf.org>
<http://tools.ietf.org>.

The IETF Secretariat





___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https:/

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-mtls-00.txt

[Sergey Beryozkin]

Hi Brian

Thanks, a minor typo in the example,
"x5t#s256" as opposed to "x5t#S256"

(sorry if it was already reported, might've missed it)

Cheers, Sergey
On 30/03/17 22:15, Brian Campbell wrote:

This document, which I hope to present and discuss briefly at tomorrow's
meeting, replaces (but keeps the feature) the Mutual TLS Authentication
for OAuth Clients

that was published leading up to the Seoul meeting
 and
adds mutual TLS sender constrained access to OAuth protected resources.
The concept for the latter was largely derived from one of the options
in the JPOP draft
. I apologize
for the 11th hour publication but hope some folks will have a chance to
read it.

-- Forwarded message --
From: ** mailto:internet-dra...@ietf.org>>
Date: Thu, Mar 30, 2017 at 3:49 PM
Subject: New Version Notification for draft-campbell-oauth-mtls-00.txt
To: Brian Campbell mailto:brian.d.campb...@gmail.com>>, Nat Sakimura mailto:n-sakim...@nri.co.jp>>, Torsten Lodderstedt
mailto:tors...@lodderstedt.net>>, John Bradley
mailto:ve7...@ve7jtb.com>>



A new version of I-D, draft-campbell-oauth-mtls-00.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:   draft-campbell-oauth-mtls
Revision:   00
Title:  Mutual TLS Profiles for OAuth Clients
Document date:  2017-03-30
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt

Status:
 https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/

Htmlized:   https://tools.ietf.org/html/draft-campbell-oauth-mtls-00

Htmlized:
 https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00



Abstract:
   This document describes Transport Layer Security (TLS) mutual
   authentication using X.509 certificates as a mechanism for both OAuth
   client authentication to the token endpoint as well as for sender
   constrained access to OAuth protected resources.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org
.

The IETF Secretariat





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt

[Sergey Beryozkin]

Hi John

I see a line in our implementation checking that if a response_type is 
also available as a query parameter then it must match the request claim 
value.
Would it make sense to require checking all the well-known query 
parameters and if they exist - enforcing they must also be available in 
the request object ?


Sergey
On 31/03/17 05:14, John Bradley wrote:

They are mutually exclusive.



However there are two options as to how the authorization endpoint would
treat extra query parameters like state if they are sent.



The current text causes the AS to ignore them and not return a error.
 This would be more backwards compatible with the request object in
OpenID Connect, however in reality it may cause connect clients to send
parameters as query parameters  that would be processed by a connect
server that would be ignored by a OAuth server without any obvious
error.  There may however be subtle errors downstream from missing
parameters.



The other option is to have a cleaner breaking change from Connect and
have the Authorization endpoint return a error if anything other than
the two new parameters are sent to the authorization endpoint.



I am leaning towards the latter as it is easier to debug,  and wont
allow incompatible Connect requests to be accepted without a error.   We
would have done this in Connect but couldn’t drop required parameters
from OAuth in a Connect spec.



The downside for the latter is that the client would need to know if the
AS is supporting The Connect version or the OAuth version.



One of the typical conundrums around how to deal with doing the best
going forward thing vs not blowing up older implementations.



In the current proposal a client could put the required parameters both
places and the same request would work on servers supporting both the
Connect and OAuth versions.



John B.

Sent from Mail  for
Windows 10



*From: *Torsten Lodderstedt 
*Sent: *March 30, 2017 11:01 PM
*To: *John Bradley 
*Cc: *Nat Sakimura ; Nat Sakimura
; IETF oauth WG 
*Subject: *Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt



I had assumed using the request object is mutual exclusive to use of URI
query parameters. Did I misinterpret the draft?



Am 30.03.2017 um 22:40 schrieb John Bradley mailto:ve7...@ve7jtb.com>>:



It is a trade off between compatibility with Connect and possible
configuration errors.



In reality it may not be compatible with Connect if the client is
sending some parameters outside the object without including them in
the object as a Connect client might.You would potentially wind
up dropping state or nonce without an error.



I asked Mike and he was leaning to making it a error to send them as
query parameters as that would be a clean change.



I think the choice is a bit of a grey area.



Sent from Mail  for
Windows 10



*From: *sakim...@gmail.com 
*Sent: *March 30, 2017 9:57 PM
*To: *John Bradley ; Nat Sakimura

*Cc: *IETF oauth WG 
*Subject: *Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt



+1

Sent from my Huawei Mobile



 Original Message 
Subject: Re: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt
From: John Bradley
To: Nat Sakimura
CC: IETF oauth WG

So I think we need to make the must ignore clearer for the
additional paramaters on the authorization endpoint.



On Mar 30, 2017 17:33, "Nat Sakimura" mailto:n...@sakimura.org>> wrote:

Not right now.

As of this writing, a client can still send duplicate
parameters in the query but they get ignored by the servers
honoring OAuth JAR. So, it is backwards compatible with
OpenID Connect in that sense (OpenID Connect sends duplicate
manatory RFC6749 parameters as the query parameters as well
just to be compliant to RFC6749). Conversely, servers that
do not support OAuth JAR will ignore request_uri etc.

On Mar 30, 2017, at 4:47 PM, Mike Jones
mailto:michael.jo...@microsoft.com>> wrote:

Is there a clear statement somewhere along the lines of
“parameters (other than “request” or “request_uri”) are
only allowed to be in the signed object if a signed
object is used”?  That’s the kind of thing I was looking
for and didn’t find.




-- Mike

*From:* John Bradley [mailto:ve7...@ve7jtb.com
]
*Sent:* Thursday, Ma

Re: [OAUTH-WG] More Criticism of JOSE

[Sergey Beryozkin]

and everyone should now start using the most secure alternative proposed 
in that very light in analysis article :-)


Sergey
On 15/03/17 15:43, Mike Schwartz wrote:

Sorry to be the bearer of bad news, but here's a negative review of JOSE:

JOSE (Javascript Object Signing and Encryption) is a Bad Standard That
Everyone Should Avoid

https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid


- Mike

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Dynamic client registration and the audience (resource) indicators

[Sergey Beryozkin]

Hi,
We'll experiment with starting supporting a "resource_uris" extension 
array property - the name is based on a 'resource' indicator property 
from the resource indicators draft, with a '_uris' added given that many 
dynamic registration properties have similar suffixes


Cheers, Sergey
On 29/11/16 10:49, Sergey Beryozkin wrote:

Hi John, All

I've been alway thinking that the reason an audience can be an array (as
indicated for ex by the JWT spec, etc) is because a client application
may need to talk to more than one RS in order to complete a single
action for the current user (ex, the client will not talk to either RS1
or RS2 but first to RS1 and then will complete the action by talking to
RS2).

Why else would a JWT access token have an array of audience values ?
https://tools.ietf.org/html/rfc7519#section-4.1.3

I agree the resource indicators can help on its own - in case no
audiences for a given client have been pre-registered or as you
suggested - to point to a specific resource at the runtime, with this
(resource) URI being validated against the pre-registered values.

But also, pre-registering a single audience during the client
registration (dynamic or static) can minimize the need to use the
resource indicators at the runtime.

I did not quite understand what you were explaining about registering
RSs with the client - I guess that client will know in advance which
RS(s) it will need to talk to do its work,

Many thanks, Sergey




On 28/11/16 22:58, John Bradley wrote:

To make something like this work with a loose coupling between the RS
and AS the format of the AT would also need to be specified.

To this point the WG has avoided standardizing AT.

Most AS probably believe they know what RS the token is going to be
used at based on scopes.
Taking those tokens and using them at other RS is arguably at-least
out of scope or arguably not allowed by the current specs.

People are perhaps abusing the specs and sending AT to RS that are not
properly audienced and can be replayed between RS.
This is really bad from a security perspective with bearer tokens.

I do however see a valid use case.

Registering RS with the client is not a bad idea, however if you
register more than one without the client saying at runtime what RS
the token is for they can still be replayed.
The client depending on design could still be tricked by a RS or
something else to get a token audienced to a different RS if the AS
dosen't know where the client is sending the token.

I don’t think registering RS gets around the need for the resource
indicator draft
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators

Typically we have thought about a tight coupling between the RS and
AS,  but now it seems people are putting more of the
intelligence/burden on the the client.

in a more dynamic system the RS might provide a list of AS that it
accepts tokens form and the client might dynamically register with one
of them.

I suspect Sergey’s AS is doing something in between.

I am hesitant to pick off just dynamic registration as there are a
number of interrelated issues that need to be thought through to
prevent security issues.

John B.







On Nov 28, 2016, at 3:47 PM, Justin Richer  wrote:

I would consider that a totally reasonable extension. You will need
to define what the behavior is if the client doesn’t provide a value
for that field: is there a default? Are there no resources available
to the client?

— Justin


On Nov 28, 2016, at 12:21 PM, Sergey Beryozkin
 wrote:

Hi All

Our AS allows for the manual client registration with the UI
offering an option to assign the audience/resource URIs to a given
Client registration with all the associated future access tokens
inheriting them.

The client will not have to follow the resource indicator
registration as recommended at [1] - the administrator who registers
the clients sets the audiences.

We'd like to achieve the same with the dynamic client registration
but my colleague noted the client metadata in the dynamic
registration request has no 'audience' property.

We will consider supporting either an 'audience' or 'resource'
property - does it sound reasonable ?

By the way, as far as [1] is concerned, should a 'resource' property
support an array of audiences ? (To support a case a client needed
to talk to several RSs to complete a given action)

Thanks, Sergey

[1]
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth






___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Dynamic client registration and the audience (resource) indicators

[Sergey Beryozkin]

Hi John, All

I've been alway thinking that the reason an audience can be an array (as 
indicated for ex by the JWT spec, etc) is because a client application 
may need to talk to more than one RS in order to complete a single 
action for the current user (ex, the client will not talk to either RS1 
or RS2 but first to RS1 and then will complete the action by talking to 
RS2).


Why else would a JWT access token have an array of audience values ?
https://tools.ietf.org/html/rfc7519#section-4.1.3

I agree the resource indicators can help on its own - in case no 
audiences for a given client have been pre-registered or as you 
suggested - to point to a specific resource at the runtime, with this 
(resource) URI being validated against the pre-registered values.


But also, pre-registering a single audience during the client 
registration (dynamic or static) can minimize the need to use the 
resource indicators at the runtime.


I did not quite understand what you were explaining about registering 
RSs with the client - I guess that client will know in advance which 
RS(s) it will need to talk to do its work,


Many thanks, Sergey




On 28/11/16 22:58, John Bradley wrote:

To make something like this work with a loose coupling between the RS and AS 
the format of the AT would also need to be specified.

To this point the WG has avoided standardizing AT.

Most AS probably believe they know what RS the token is going to be used at 
based on scopes.
Taking those tokens and using them at other RS is arguably at-least out of 
scope or arguably not allowed by the current specs.

People are perhaps abusing the specs and sending AT to RS that are not properly 
audienced and can be replayed between RS.
This is really bad from a security perspective with bearer tokens.

I do however see a valid use case.

Registering RS with the client is not a bad idea, however if you register more 
than one without the client saying at runtime what RS the token is for they can 
still be replayed.
The client depending on design could still be tricked by a RS or something else 
to get a token audienced to a different RS if the AS dosen't know where the 
client is sending the token.

I don’t think registering RS gets around the need for the resource indicator 
draft https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators

Typically we have thought about a tight coupling between the RS and AS,  but 
now it seems people are putting more of the intelligence/burden on the the 
client.

in a more dynamic system the RS might provide a list of AS that it accepts 
tokens form and the client might dynamically register with one of them.

I suspect Sergey’s AS is doing something in between.

I am hesitant to pick off just dynamic registration as there are a number of 
interrelated issues that need to be thought through to prevent security issues.

John B.







On Nov 28, 2016, at 3:47 PM, Justin Richer  wrote:

I would consider that a totally reasonable extension. You will need to define 
what the behavior is if the client doesn’t provide a value for that field: is 
there a default? Are there no resources available to the client?

— Justin


On Nov 28, 2016, at 12:21 PM, Sergey Beryozkin  wrote:

Hi All

Our AS allows for the manual client registration with the UI offering an option 
to assign the audience/resource URIs to a given Client registration with all 
the associated future access tokens inheriting them.

The client will not have to follow the resource indicator registration as 
recommended at [1] - the administrator who registers the clients sets the 
audiences.

We'd like to achieve the same with the dynamic client registration but my 
colleague noted the client metadata in the dynamic registration request has no 
'audience' property.

We will consider supporting either an 'audience' or 'resource' property - does 
it sound reasonable ?

By the way, as far as [1] is concerned, should a 'resource' property support an 
array of audiences ? (To support a case a client needed to talk to several RSs 
to complete a given action)

Thanks, Sergey

[1] https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Dynamic client registration and the audience (resource) indicators

[Sergey Beryozkin]

Hi Justin

Thanks, may be if a value for that field is not set, then, by default, a 
client can use the access tokens against the arbitrary RS servers, as 
far as I understand this is what happens by default right now ?


Cheers, Sergey

On 28/11/16 18:47, Justin Richer wrote:

I would consider that a totally reasonable extension. You will need to define 
what the behavior is if the client doesn’t provide a value for that field: is 
there a default? Are there no resources available to the client?

 — Justin


On Nov 28, 2016, at 12:21 PM, Sergey Beryozkin  wrote:

Hi All

Our AS allows for the manual client registration with the UI offering an option 
to assign the audience/resource URIs to a given Client registration with all 
the associated future access tokens inheriting them.

The client will not have to follow the resource indicator registration as 
recommended at [1] - the administrator who registers the clients sets the 
audiences.

We'd like to achieve the same with the dynamic client registration but my 
colleague noted the client metadata in the dynamic registration request has no 
'audience' property.

We will consider supporting either an 'audience' or 'resource' property - does 
it sound reasonable ?

By the way, as far as [1] is concerned, should a 'resource' property support an 
array of audiences ? (To support a case a client needed to talk to several RSs 
to complete a given action)

Thanks, Sergey

[1] https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Dynamic client registration and the audience (resource) indicators

[Sergey Beryozkin]

Hi All

Our AS allows for the manual client registration with the UI offering an 
option to assign the audience/resource URIs to a given Client 
registration with all the associated future access tokens inheriting them.


The client will not have to follow the resource indicator registration 
as recommended at [1] - the administrator who registers the clients sets 
the audiences.


We'd like to achieve the same with the dynamic client registration but 
my colleague noted the client metadata in the dynamic registration 
request has no 'audience' property.


We will consider supporting either an 'audience' or 'resource' property 
- does it sound reasonable ?


By the way, as far as [1] is concerned, should a 'resource' property 
support an array of audiences ? (To support a case a client needed to 
talk to several RSs to complete a given action)


Thanks, Sergey

[1] https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Sergey Beryozkin]

On 10/11/16 21:57, Sergey Beryozkin wrote:

On 10/11/16 20:10, Vladimir Dzhuvinov wrote:



On 03/11/16 19:11, Sergey Beryozkin wrote:

Hi

In our implementation we support the following scenario:
- the client registers its public certificate during the client
registration


Did you extend the standard client reg API for this purpose?

No. Should there be an option in the client reg API ?


How does the cert registration actually take place?

The encoded certificate is an optional property of the Client class
which is part of the larger OAuth2 model. The clients are registered out
of band - the assumption that the product integrating our model will let
the admins upload a certificate associated with a given client,
alongside all the other information one would typically allocate at a
client registration time via some UI page.
In a particular integration instance I'm aware of no such option to
upload the certs is offered yet

Sergey




- next, mutual/two-way TLS is used, so AccessTokenService tries to
figure out the client_id. At the moment it assumes the client_id is
(Java) X509Certificate.getSubjectX500Principal().getName().

Next it retrieves a client with this name and compares the TLS
client/peer certificate against the pre-registered one.

I think it may be interesting to explore further if client_id can
become optional based on what Samuel said.

For example, indeed I can see how I can update our code to have a
mapping between some of client certificate's properties and a client
id stored within a Client registration.

The question is how to find a given Client registration effectively
given only a certificate, without an optional client_id. One would
need to have a map between these client certificate attribute and
client_id or Clients.

Cheers, Sergey



On 03/11/16 16:48, Samuel Erdtman wrote:

I can see your point, maybe the client_id will not be in the
certificate.
If I had an AS I would select to trust one or several CAs and then
create certificate mappings between certificate serial number (or some
other unique attribute in the certificate) and client_id. If I were to
bind a specific certificate to a client_id I lose the flexibility of
the
PKI (maybe what you want).

I think multiple certificates might not be a uncommon situation
especially if you call ASs from different organizations because they
will trust different CAs.

//Samuel


On Thu, Nov 3, 2016 at 5:32 PM, Justin Richer mailto:jric...@mit.edu>> wrote:

Jim,

In those circumstances, are the clients generally calling multiple
different services? Or just one? For those that call multiple
services, are they using multiple (different) client certificates?

I’m not saying the client would issue its own cert in all cases —
much more common is what I’ve seen, with clients being assigned a
certificate from a trusted CA, and then services that the client
talks to being told to trust that CA and also assign the CN/DN of
the cert a set of privileges. What I *haven’t* seen is a client
being issued multiple certificates to talk to multiple systems.
That
latter case is common enough in the OAuth world that I wouldn’t
want
us to paint ourselves in a corner.

 — Justin


On Nov 3, 2016, at 10:31 AM, Jim Manico mailto:j...@manicode.com>> wrote:

Thanks Justin. I use several security intel services and they all
have different cert delivery mechanisms for mutual TLS. It's
•rare• for services to let clients choose certs, they are usually
assigned to users by each service from my experience.

Aloha,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805 

On Nov 3, 2016, at 8:51 AM, Justin Richer mailto:jric...@mit.edu>> wrote:


Yes, I elided the certificate issuance process. The point remains
the same: you're not going to be submitting a CSR to the same
party you're getting your client_id from, usually. If the draft
assumes that, then it's incredibly limiting.


Do people really use separate TLS client certs for separate
connections in the wild? I've personally never seen that. What
I've seen is that a piece of software gets its certificate that
it uses to make whatever connections it needs to make.


 -- Justin


On 11/3/2016 8:48 AM, Jim Manico wrote:

Just to be clear, the relationship should more like...

AS issues public key to clients, or client sends public key to
AS. The authorities job is NOT to give the client the public
key, but to sign the public key for authenticity. It's bad
practice to accept the full cert (pub key+signature) from an
authority. If an authority is creating your public key, they are
also creating your private key bad.

> The client will use the same cert across multiple connections,
possibly multiple AS's, but the same isn't true of the
client_id.

   

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Sergey Beryozkin]

ding of a
self-signed certificate using dynamic registration, much the
way that we already allow binding of a client-generated JWK today.

I do think that more examples and guidance are warranted,
though, to help AS developers.

 -- Justin


On 11/2/2016 5:03 PM, Brian Campbell wrote:


On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman
mailto:sam...@erdtman.se>> wrote:


I agree it is written so that the connection to the
certificate is implicitly required but I think it would be
better if it was explicit written since the lack of a
connection would result in a potential security hole.


That's fair. I agree it can be made more explicit and that it
be good to do so.



When it comes to the client_id I think subject common name
or maybe subject serial numbers will be the common
location, and I think an example would be valuable.



In my experience and the way we built support for mutual TLS
OAuth client auth the client_id value does not appear in the
certificate anywhere. I'm not saying it can't happen but don't
think it's particularly common.

I can look at adding some examples, if there's some consensus
that they'd be useful and this document moves forward.




I´m not saying it is a bad Idea just that I would prefer
if it was not a MUST.
With very limited addition of code it is just as easy to
get the certificate attribute for client id as it is to
get it from the HTTP request data (at least in java). I
also think that with the requirement to match the incoming
certificate in some way one has to read out the
certificate that was used to establish the connection to
do some kind of matching.


Getting data out of the certificate isn't a concern. I just
believe that the constancy of having the client id parameter
is worth the potential small amount duplicate data in some
cases. It's just a -00 draft though and if the WG wants to
proceed with this document, we seek further input and work
towards some consensus.



___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>


___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>







___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Sergey Beryozkin

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWS JWT Access Tokens and resource audiences

[Sergey Beryozkin]

Hi Brian

Thanks, 'cid' is a proper compact name :-), I've made our code 
configurable - to support reporting a client_id property either as a 
'client_id' or 'cid' claim.


Cheers, Sergey

On 12/08/16 23:30, Brian Campbell wrote:

Yeah, the client typically isn't the/an audience of an access token. The
AT is opaque to the client and the client never processes or validates
it. So aud would have the resource(s) and something else could carry the
client id.

FWIW, token exchange is looking to define and register "cid" as a JWT
claim for the client identifier:
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-05#section-4.3

On Fri, Aug 12, 2016 at 4:13 AM, Sergey Beryozkin mailto:sberyoz...@gmail.com>> wrote:

Hi,


After updating my earlier code (where 'client_id' was set as the
standard JWT access token 'aud' property) to use 'aud' to represent
the resource audiences I'm now thinking how to represent a
'client_id' in this token.

For now if I'm using a 'client_id' claim, to be consistent with a
standard token introspection response.

The other thing is how to represent a name of the user who
authorized the code grant which was exchanged for this token.

Again I'm using a "username" claim, to be consistent with a standard
token introspection response.

Also thinking, what value if any a 'sub' claim in such a token
should have. I'm setting it to a unique user identifier (similarly
to IdToken).

Any comments are welcome

Sergey


On 11/08/16 23:30, Sergey Beryozkin wrote:

Hi John
On 11/08/16 23:24, John Bradley wrote:

I think most people put the a resource URI in the aud.

Connect uses the client ID as that is bit more stable than
trying to
use a redirect URI when there could be multiple ones.
Given that a resource server doesn’t typically have a
client_id the
resource uri make a reasonable value.

You could put it in resource if you like, but that is
probably not
what others are doing.

I was suspecting I might be on my own here yes :-)


It may be time for a interoperable JWT access token profile
of some sort.


+1

We keep getting close with some of the PoP stuff but only
specify parts.


Thanks, Sergey


John B.

On Aug 11, 2016, at 6:16 PM, Sergey Beryozkin
mailto:sberyoz...@gmail.com>>
wrote:

Hi All

Awhile back I was asking why would self-contained JWS
JWT access
tokens would be used (as opposed to JWE JWTs), my
concern was that
anyone with a JWT library can read this token's content
- but as I
was explained that should not be a problem if such a JWS
JWT token
contains non-sensitive information. Besides, in some
cases, it gives
RS an option to validate this JWS JWT locally, without
having to make
a remote validation call.

So I've started experimenting and the immediate question
I have is
this one: which claim should one use to represent a
resource server
audience to get the most inter-operable RS level
validation logic ?

For example, a given RS may talk to different 3rd party
authorization
servers, say AS1 (vendor1) and AS2 (vendor2), and either
AS1 or AS2
JWS JWT tokens that this RS validates locally should
ideally use the
same claim to represent a resource audience. RS
validation logic is
written independently (without using AS1 or AS2 aware
validation
libraries).

We do expect such requirements coming in our
deployments. AS1 &
independent validation logic is already in use. Just a
matter of time
before AS2 is introduced.

So JWT has a standard 'aud' claim - but I believe this
should be a
'clientId' of the client a token is issued to, similarly
to the way
the 'aud' is treated in IdToken.

So I've prototyped the code where JWT has these claims:

"aud" = clientId
"resource" = 'http://myResourceServer'

where 'resourc

Re: [OAUTH-WG] JWS JWT Access Tokens and resource audiences

[Sergey Beryozkin]

Hi,


After updating my earlier code (where 'client_id' was set as the 
standard JWT access token 'aud' property) to use 'aud' to represent the 
resource audiences I'm now thinking how to represent a 'client_id' in 
this token.


For now if I'm using a 'client_id' claim, to be consistent with a 
standard token introspection response.


The other thing is how to represent a name of the user who authorized 
the code grant which was exchanged for this token.


Again I'm using a "username" claim, to be consistent with a standard 
token introspection response.


Also thinking, what value if any a 'sub' claim in such a token should 
have. I'm setting it to a unique user identifier (similarly to IdToken).


Any comments are welcome

Sergey

On 11/08/16 23:30, Sergey Beryozkin wrote:

Hi John
On 11/08/16 23:24, John Bradley wrote:

I think most people put the a resource URI in the aud.

Connect uses the client ID as that is bit more stable than trying to
use a redirect URI when there could be multiple ones.
Given that a resource server doesn’t typically have a client_id the
resource uri make a reasonable value.

You could put it in resource if you like, but that is probably not
what others are doing.

I was suspecting I might be on my own here yes :-)



It may be time for a interoperable JWT access token profile of some sort.


+1


We keep getting close with some of the PoP stuff but only specify parts.


Thanks, Sergey



John B.

On Aug 11, 2016, at 6:16 PM, Sergey Beryozkin 
wrote:

Hi All

Awhile back I was asking why would self-contained JWS JWT access
tokens would be used (as opposed to JWE JWTs), my concern was that
anyone with a JWT library can read this token's content - but as I
was explained that should not be a problem if such a JWS JWT token
contains non-sensitive information. Besides, in some cases, it gives
RS an option to validate this JWS JWT locally, without having to make
a remote validation call.

So I've started experimenting and the immediate question I have is
this one: which claim should one use to represent a resource server
audience to get the most inter-operable RS level validation logic ?

For example, a given RS may talk to different 3rd party authorization
servers, say AS1 (vendor1) and AS2 (vendor2), and either AS1 or AS2
JWS JWT tokens that this RS validates locally should ideally use the
same claim to represent a resource audience. RS validation logic is
written independently (without using AS1 or AS2 aware validation
libraries).

We do expect such requirements coming in our deployments. AS1 &
independent validation logic is already in use. Just a matter of time
before AS2 is introduced.

So JWT has a standard 'aud' claim - but I believe this should be a
'clientId' of the client a token is issued to, similarly to the way
the 'aud' is treated in IdToken.

So I've prototyped the code where JWT has these claims:

"aud" = clientId
"resource" = 'http://myResourceServer'

where 'resource' is borrowed from OAuth2 Resource Indicators draft
and represent a specific RS target address, the resource server
audience.

Am I on the right path ? How would others do it when facing a task of
including a resource audience in a self-contained JWS JWT access token ?

Many thanks, Sergey

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth






___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] How to participate in OAuth2 IETF meetings

[Sergey Beryozkin]

Hi John

On 11/08/16 23:43, John Bradley wrote:

Anyone can attend IETF meetings, and we encourage new people.  We all were new 
at some point.  (I have always been old but am the exception)


Wait and see a newcomer like myself and you may get surprised :-)



We meet 3 times a year.  The meetings are listed at 
https://www.ietf.org/meeting/upcoming.html

There are sometimes interim meetings that are announced on the list.  We just 
had one on Security in Germany.

Often there more informal meetings at IIW 
http://www.internetidentityworkshop.com/ in California twice a year and at 
OpenID workshops.


We'll keep an eye on the upcoming calendar and the list announcements.

Many thanks, Sergey


John B.


On Aug 11, 2016, at 6:35 PM, Sergey Beryozkin  wrote:

Hi All

Who can participate in OAuth2 IETF meetings/workshops ?
I've checked the meeting archives, apparently the 'Newcomers' can be there but 
how formal the process is and how OAuth2-'qualified' the newcomers should be ?

I'm interested in talking to other OAuth2 implementers f2f and myself and my 
other colleagues might also provide some input to the standardization effort.

Are the rules for OIDC & JOSE workshops different (I can ask on specific lists 
for more details if yes)

We might be able to join sometimes depending on the locality, times, and other 
constraints.



Cheers, Sergey

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] How to participate in OAuth2 IETF meetings

[Sergey Beryozkin]

Hi All

Who can participate in OAuth2 IETF meetings/workshops ?
I've checked the meeting archives, apparently the 'Newcomers' can be 
there but how formal the process is and how OAuth2-'qualified' the 
newcomers should be ?


I'm interested in talking to other OAuth2 implementers f2f and myself 
and my other colleagues might also provide some input to the 
standardization effort.


Are the rules for OIDC & JOSE workshops different (I can ask on specific 
lists for more details if yes)


We might be able to join sometimes depending on the locality, times, and 
other constraints.




Cheers, Sergey

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWS JWT Access Tokens and resource audiences

[Sergey Beryozkin]

Hi John
On 11/08/16 23:24, John Bradley wrote:

I think most people put the a resource URI in the aud.

Connect uses the client ID as that is bit more stable than trying to use a 
redirect URI when there could be multiple ones.
Given that a resource server doesn’t typically have a client_id the resource 
uri make a reasonable value.

You could put it in resource if you like, but that is probably not what others 
are doing.

I was suspecting I might be on my own here yes :-)



It may be time for a interoperable JWT access token profile of some sort.


+1


We keep getting close with some of the PoP stuff but only specify parts.


Thanks, Sergey



John B.

On Aug 11, 2016, at 6:16 PM, Sergey Beryozkin  wrote:

Hi All

Awhile back I was asking why would self-contained JWS JWT access tokens would 
be used (as opposed to JWE JWTs), my concern was that anyone with a JWT library 
can read this token's content - but as I was explained that should not be a 
problem if such a JWS JWT token contains non-sensitive information. Besides, in 
some cases, it gives RS an option to validate this JWS JWT locally, without 
having to make a remote validation call.

So I've started experimenting and the immediate question I have is this one: 
which claim should one use to represent a resource server audience to get the 
most inter-operable RS level validation logic ?

For example, a given RS may talk to different 3rd party authorization servers, 
say AS1 (vendor1) and AS2 (vendor2), and either AS1 or AS2 JWS JWT tokens that 
this RS validates locally should ideally use the same claim to represent a 
resource audience. RS validation logic is written independently (without using 
AS1 or AS2 aware validation libraries).

We do expect such requirements coming in our deployments. AS1 & independent 
validation logic is already in use. Just a matter of time before AS2 is introduced.

So JWT has a standard 'aud' claim - but I believe this should be a 'clientId' 
of the client a token is issued to, similarly to the way the 'aud' is treated 
in IdToken.

So I've prototyped the code where JWT has these claims:

"aud" = clientId
"resource" = 'http://myResourceServer'

where 'resource' is borrowed from OAuth2 Resource Indicators draft and 
represent a specific RS target address, the resource server audience.

Am I on the right path ? How would others do it when facing a task of including 
a resource audience in a self-contained JWS JWT access token ?

Many thanks, Sergey

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] JWS JWT Access Tokens and resource audiences

[Sergey Beryozkin]

Hi All

Awhile back I was asking why would self-contained JWS JWT access tokens 
would be used (as opposed to JWE JWTs), my concern was that anyone with 
a JWT library can read this token's content - but as I was explained 
that should not be a problem if such a JWS JWT token contains 
non-sensitive information. Besides, in some cases, it gives RS an option 
to validate this JWS JWT locally, without having to make a remote 
validation call.


So I've started experimenting and the immediate question I have is this 
one: which claim should one use to represent a resource server audience 
to get the most inter-operable RS level validation logic ?


For example, a given RS may talk to different 3rd party authorization 
servers, say AS1 (vendor1) and AS2 (vendor2), and either AS1 or AS2 JWS 
JWT tokens that this RS validates locally should ideally use the same 
claim to represent a resource audience. RS validation logic is written 
independently (without using AS1 or AS2 aware validation libraries).


We do expect such requirements coming in our deployments. AS1 & 
independent validation logic is already in use. Just a matter of time 
before AS2 is introduced.


So JWT has a standard 'aud' claim - but I believe this should be a 
'clientId' of the client a token is issued to, similarly to the way the 
'aud' is treated in IdToken.


So I've prototyped the code where JWT has these claims:

"aud" = clientId
"resource" = 'http://myResourceServer'

where 'resource' is borrowed from OAuth2 Resource Indicators draft and 
represent a specific RS target address, the resource server audience.


Am I on the right path ? How would others do it when facing a task of 
including a resource audience in a self-contained JWS JWT access token ?


Many thanks, Sergey

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Using IdToken instead of Access token

[Sergey Beryozkin]

Hi Nat
On 05/08/16 11:16, Nat Sakimura wrote:

I can sort of understand why people would want to do it, and there are
legitimate cases.

This is the case where the RS is in fact an AS (ASr)  in that resource
domain and the RS is dependent on the federated AS (ASf) for the
authentication. In such a case, the ASf cannot really make the access
decision.
It is the ASr that makes the decision based on the user authentication
results, and possibly the authorisation result at ASf combined. To the
ASf, the 'client' is the combination of the app that the user is using
and the RS. So, the app sends the ID Token to the RS=ASr. This pattern
is perfectly legitimate as long as the RS is also in the audience.

We've noticed that IdToken may have >1 audiences, in addition to the 
client audience, but were not sure what extra audiences would be there, 
so I can see now.


In this case, when RS acts as ASr, and IdToken lists this RS in the 
audience, is it still recommended for the client to exchange this 
IdToken for a new token via a token exchange endpoint and forwarding a 
new token to RS, or it it OK for the client to send the IdToken to RS 
bypassing the exchange ?


Thanks, Sergey


Best,

Nat


2016年8月5日(金) 5:58 John Bradley mailto:ve7...@ve7jtb.com>>:

The token exchange spec allows for the token issued to have claims
about the subject of the input token.   This is what we generally
think about as impersonation.
That is really the same as a normal OAuth access token for the most
part.

You can also ask for a composite token that contains claims about
the presenter and the original subject.   This allows for the
auditing of who is making the request for the subject.

This sort of composite token was introduced in WS-Trust 1.4 and is
called ActAs in that spec and we refer to as delegation.

This is desired when a RS (A) receives a access token and then needs
to become a client (A) to access another service in the context of
the access token.

The second RS (B) is protected and can’t be access directly by the
the original OAuth client.  The client (A) needs a new access token
based on its client credential plus the original access token to get
a token that RS (B)  will accept.   RS (B) also wants to know who
the client that is accessing it for audit or other reasons.

That is one of the things that the new delegated token type is for.
The impersonation type is basically the same sort of impersonation
type token that we use now.

I admit that OAuth is vague about delegation vs impersonation and
they are generally left as implementation decisions as the tokens
are considered opaque.

For token exchange we wanted to be more explicit so that the client
has more control over the exchange.

I hope that helps.

John B.

> On Aug 4, 2016, at 12:26 PM, Sergey Beryozkin
mailto:sberyoz...@gmail.com>> wrote:
>
> Hi John
>
> I think it is closer to what I'm trying to understand :-). Let me
work with the text below, I'll likely have few more questions to
follow later on
>
> Thanks, Sergey
>
> On 04/08/16 17:04, John Bradley wrote:
>> The id_token and access token have different semantics, and quite
possable possibly formats.
>>
>> So the AT that comes with the id_token will be useful at RS
associated with the AS, but it may not be useful at other API the
client wants to access and that is generally where we run into the
use case for token exchange.
>>
>> In the case of talking to a third party API it may be useful to
have that API have a token exchange endpoint where a client can
exchange a id_token/JWT for an access token.
>> That is clearer and likely more secure given a confidential
client  than just using the id_token as a access token directly.
>>
>> Now I do understand people do that now.
>>
>> In the hopefully near future once we have token binding as a
proof of possession mechanism it will be come clearer that you cant
take a id_token that is bound to the browser presenting the token to
the client and directly re use that as a secure access token.   The
AT and RT issued with that token will be bound to the client so that
the RS can validate them.
>>
>> There are a lot of bad patterns possible with bearer tokens.   I
prefer to try to avoid them so that people will be in a better
position when we move off bearer tokens for increased security.
>>
>> John B.
>>> On Aug 4, 2016, at 11:17 AM, Sergey Beryozkin
mailto:sberyoz...@gmail.com>> wrote:
>>>
>>> Hi Phil
>>>
>>> On 04/08/16 15:01, Phil Hunt (IDM) wrote:
>>>> You mig

Re: [OAUTH-WG] Using IdToken instead of Access token

[Sergey Beryozkin]

Hi John

On 04/08/16 21:58, John Bradley wrote:

The token exchange spec allows for the token issued to have claims about the 
subject of the input token.   This is what we generally think about as 
impersonation.
That is really the same as a normal OAuth access token for the most part.

You can also ask for a composite token that contains claims about the presenter 
and the original subject.   This allows for the auditing of who is making the 
request for the subject.

This sort of composite token was introduced in WS-Trust 1.4 and is called ActAs 
in that spec and we refer to as delegation.

This is desired when a RS (A) receives a access token and then needs to become 
a client (A) to access another service in the context of the access token.

The second RS (B) is protected and can’t be access directly by the the original 
OAuth client.  The client (A) needs a new access token based on its client 
credential plus the original access token to get a token that RS (B)  will 
accept.   RS (B) also wants to know who the client that is accessing it for 
audit or other reasons.

That is one of the things that the new delegated token type is for.  The 
impersonation type is basically the same sort of impersonation type token that 
we use now.

I admit that OAuth is vague about delegation vs impersonation and they are 
generally left as implementation decisions as the tokens are considered opaque.

For token exchange we wanted to be more explicit so that the client has more 
control over the exchange.

I hope that helps.


It does.
Cheers, Sergey



John B.


On Aug 4, 2016, at 12:26 PM, Sergey Beryozkin  wrote:

Hi John

I think it is closer to what I'm trying to understand :-). Let me work with the 
text below, I'll likely have few more questions to follow later on

Thanks, Sergey

On 04/08/16 17:04, John Bradley wrote:

The id_token and access token have different semantics, and quite possable 
possibly formats.

So the AT that comes with the id_token will be useful at RS associated with the 
AS, but it may not be useful at other API the client wants to access and that 
is generally where we run into the use case for token exchange.

In the case of talking to a third party API it may be useful to have that API 
have a token exchange endpoint where a client can exchange a id_token/JWT for 
an access token.
That is clearer and likely more secure given a confidential client  than just 
using the id_token as a access token directly.

Now I do understand people do that now.

In the hopefully near future once we have token binding as a proof of 
possession mechanism it will be come clearer that you cant take a id_token that 
is bound to the browser presenting the token to the client and directly re use 
that as a secure access token.   The AT and RT issued with that token will be 
bound to the client so that the RS can validate them.

There are a lot of bad patterns possible with bearer tokens.   I prefer to try 
to avoid them so that people will be in a better position when we move off 
bearer tokens for increased security.

John B.

On Aug 4, 2016, at 11:17 AM, Sergey Beryozkin  wrote:

Hi Phil

On 04/08/16 15:01, Phil Hunt (IDM) wrote:

You might be munging two different flows with different semantics together.

First flow is use oidc to authen the user to the client.

Second flow is normal oauth authorization to get an at to access the resource.

Often the OP AS is different from the RS's AS and the rs needs a proper 
"delegation" access token.

Indeed, this is more or less what I've been saying in our private discussions.

But as I said to in my response to Mike, I see a demand to have IdToken 
propagated and given the token exchange draft has a dedicated 'impersonation' 
section I'm assuming there's a need for it.

For example, I was checking the archives, could see Brian Campbell quoting 
Vittorio Bertocci:
"To summarize our main use case: we use [a token exchange like protocol] for 
achieving user impersonation thru tiers, or delegation for confidential clients which do 
not have any web UX..."

The former case there suggests that if a client has a web UI they authenticate 
the user first and then start impersonating.

I'm advocating for the clients to use the access tokens. The clients can 
requests the extra scopes while authenticating the user and if the user 
approves these scopes the client can continue using AT on behalf of the client, 
and using IdToken to only interact with the user.

But I'm finding it difficult to explain (show a clear differentiator) when the 
client should use AT and when they should use IdToken to impersonate a user and 
get a new token (via the token exchange)...

Sergey


Phil


On Aug 4, 2016, at 6:00 AM, Mike Schwartz  wrote:

Sergey,

Since no one answered your question, let me pose a few questions to your 
questions!

Wouldn't it give you more flexibility to issue a different token to
represent a

Re: [OAUTH-WG] Using IdToken instead of Access token

[Sergey Beryozkin]

Hi John

I think it is closer to what I'm trying to understand :-). Let me work 
with the text below, I'll likely have few more questions to follow later on


Thanks, Sergey

On 04/08/16 17:04, John Bradley wrote:

The id_token and access token have different semantics, and quite possable 
possibly formats.

So the AT that comes with the id_token will be useful at RS associated with the 
AS, but it may not be useful at other API the client wants to access and that 
is generally where we run into the use case for token exchange.

In the case of talking to a third party API it may be useful to have that API 
have a token exchange endpoint where a client can exchange a id_token/JWT for 
an access token.
That is clearer and likely more secure given a confidential client  than just 
using the id_token as a access token directly.

Now I do understand people do that now.

In the hopefully near future once we have token binding as a proof of 
possession mechanism it will be come clearer that you cant take a id_token that 
is bound to the browser presenting the token to the client and directly re use 
that as a secure access token.   The AT and RT issued with that token will be 
bound to the client so that the RS can validate them.

There are a lot of bad patterns possible with bearer tokens.   I prefer to try 
to avoid them so that people will be in a better position when we move off 
bearer tokens for increased security.

John B.

On Aug 4, 2016, at 11:17 AM, Sergey Beryozkin  wrote:

Hi Phil

On 04/08/16 15:01, Phil Hunt (IDM) wrote:

You might be munging two different flows with different semantics together.

First flow is use oidc to authen the user to the client.

Second flow is normal oauth authorization to get an at to access the resource.

Often the OP AS is different from the RS's AS and the rs needs a proper 
"delegation" access token.

Indeed, this is more or less what I've been saying in our private discussions.

But as I said to in my response to Mike, I see a demand to have IdToken 
propagated and given the token exchange draft has a dedicated 'impersonation' 
section I'm assuming there's a need for it.

For example, I was checking the archives, could see Brian Campbell quoting 
Vittorio Bertocci:
"To summarize our main use case: we use [a token exchange like protocol] for 
achieving user impersonation thru tiers, or delegation for confidential clients which do 
not have any web UX..."

The former case there suggests that if a client has a web UI they authenticate 
the user first and then start impersonating.

I'm advocating for the clients to use the access tokens. The clients can 
requests the extra scopes while authenticating the user and if the user 
approves these scopes the client can continue using AT on behalf of the client, 
and using IdToken to only interact with the user.

But I'm finding it difficult to explain (show a clear differentiator) when the 
client should use AT and when they should use IdToken to impersonate a user and 
get a new token (via the token exchange)...

Sergey


Phil


On Aug 4, 2016, at 6:00 AM, Mike Schwartz  wrote:

Sergey,

Since no one answered your question, let me pose a few questions to your 
questions!

Wouldn't it give you more flexibility to issue a different token to
represent access to the RS API? In terms of passing user claims,
couldn't this be done via parameters in the API? Are you trying to do
more with OpenID Connect than was anticpiated in the design?
The id_token has an audience, are you including more than one client in that
audience? Would it make sense to look at token exchange and downscope the token?
If you are looking for a profile of OAuth2, might UMA work?

I think you're not alone in wondering what the answer to all these questions 
are..

- Mike


-
Michael Schwartz
Gluu
http://gluu.org


Message: 3
Date: Wed, 3 Aug 2016 11:08:29 +0100
From: Sergey Beryozkin 
To: "oauth@ietf.org" 
Subject: [OAUTH-WG] Using IdToken instead of Access token
Message-ID: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi All
I hope this question is better suited for this list. Will have no
problems redirecting it to the openid-connect list instead.
Consider a user working with the client web application (OIDC RP) which
authenticates the user with the OIDC authorization code flow at the end
of which the client gets AccessToken + IdToken. Next the user requests
something from the client which needs to access the RS to complete this
request.
And the idea is to have the client pass IdToken to RS and use various
user claims inside this IdToken to enforce the access control at the RS
level. My position it is likely wrong but I guess I may be missing
something that will be either in favor or against it.
The reason I think it is wrong is that if the client is using a code
flow then the right approach for staying within t

Re: [OAUTH-WG] Using IdToken instead of Access token

[Sergey Beryozkin]

On 04/08/16 16:48, Phil Hunt (IDM) wrote:

This is as bad as assuming an access token means someone was authenticated.

In this case the audience of the id token is not the resource and other badness 
may ensue.


I'm not sure what this comment is related to.

Did you see what I'm asking about ? I'm repeating that I'm not 
advocating to use IdTokens as AccessTokens; IdTokens are for the client 
to interact with the user, AccessTokens are for the client to access RS 
on behalf of the user.


But there's a token exchange draft having a section on the 
impersonation. There must be a reason it is there. Trying to figure

how it is related to the well known tokens (IdToken, AccessToken)

Sergey



Phil


On Aug 4, 2016, at 8:17 AM, Sergey Beryozkin  wrote:

Hi Phil


On 04/08/16 15:01, Phil Hunt (IDM) wrote:
You might be munging two different flows with different semantics together.

First flow is use oidc to authen the user to the client.

Second flow is normal oauth authorization to get an at to access the resource.

Often the OP AS is different from the RS's AS and the rs needs a proper 
"delegation" access token.

Indeed, this is more or less what I've been saying in our private discussions.

But as I said to in my response to Mike, I see a demand to have IdToken 
propagated and given the token exchange draft has a dedicated 'impersonation' 
section I'm assuming there's a need for it.

For example, I was checking the archives, could see Brian Campbell quoting 
Vittorio Bertocci:
"To summarize our main use case: we use [a token exchange like protocol] for 
achieving user impersonation thru tiers, or delegation for confidential clients which do 
not have any web UX..."

The former case there suggests that if a client has a web UI they authenticate 
the user first and then start impersonating.

I'm advocating for the clients to use the access tokens. The clients can 
requests the extra scopes while authenticating the user and if the user 
approves these scopes the client can continue using AT on behalf of the client, 
and using IdToken to only interact with the user.

But I'm finding it difficult to explain (show a clear differentiator) when the 
client should use AT and when they should use IdToken to impersonate a user and 
get a new token (via the token exchange)...

Sergey


Phil


On Aug 4, 2016, at 6:00 AM, Mike Schwartz  wrote:

Sergey,

Since no one answered your question, let me pose a few questions to your 
questions!

Wouldn't it give you more flexibility to issue a different token to
represent access to the RS API? In terms of passing user claims,
couldn't this be done via parameters in the API? Are you trying to do
more with OpenID Connect than was anticpiated in the design?
The id_token has an audience, are you including more than one client in that
audience? Would it make sense to look at token exchange and downscope the token?
If you are looking for a profile of OAuth2, might UMA work?

I think you're not alone in wondering what the answer to all these questions 
are..

- Mike


-
Michael Schwartz
Gluu
http://gluu.org


Message: 3
Date: Wed, 3 Aug 2016 11:08:29 +0100
From: Sergey Beryozkin 
To: "oauth@ietf.org" 
Subject: [OAUTH-WG] Using IdToken instead of Access token
Message-ID: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi All
I hope this question is better suited for this list. Will have no
problems redirecting it to the openid-connect list instead.
Consider a user working with the client web application (OIDC RP) which
authenticates the user with the OIDC authorization code flow at the end
of which the client gets AccessToken + IdToken. Next the user requests
something from the client which needs to access the RS to complete this
request.
And the idea is to have the client pass IdToken to RS and use various
user claims inside this IdToken to enforce the access control at the RS
level. My position it is likely wrong but I guess I may be missing
something that will be either in favor or against it.
The reason I think it is wrong is that if the client is using a code
flow then the right approach for staying within the OAuth2 'world' is to
use the access token to talk to RS and use IdToken only for the purpose
of interacting with the user. The access token represents a proper user
authorization and can have the extra scopes in addition to "oidc" which
RS can depend upon in its access control restrictions.
Next I'm arguing that if the IdToken is used instead then it is the case
of the client impersonating the user. And refer to the STS for the REST
of Us draft (I have a separate series of question on that draft). I'm
saying the impersonation can work but ignoring the access tokens
completely will make the overall solution much less flexible.
I'd like to ask for some advice/guidance:
- Is it a 

Re: [OAUTH-WG] Using IdToken instead of Access token

[Sergey Beryozkin]

Hi Phil

On 04/08/16 15:01, Phil Hunt (IDM) wrote:

You might be munging two different flows with different semantics together.

First flow is use oidc to authen the user to the client.

Second flow is normal oauth authorization to get an at to access the resource.

Often the OP AS is different from the RS's AS and the rs needs a proper 
"delegation" access token.
Indeed, this is more or less what I've been saying in our private 
discussions.


But as I said to in my response to Mike, I see a demand to have IdToken 
propagated and given the token exchange draft has a dedicated 
'impersonation' section I'm assuming there's a need for it.


For example, I was checking the archives, could see Brian Campbell 
quoting Vittorio Bertocci:
"To summarize our main use case: we use [a token exchange like protocol] 
for achieving user impersonation thru tiers, or delegation for 
confidential clients which do not have any web UX..."


The former case there suggests that if a client has a web UI they 
authenticate the user first and then start impersonating.


I'm advocating for the clients to use the access tokens. The clients can 
requests the extra scopes while authenticating the user and if the user 
approves these scopes the client can continue using AT on behalf of the 
client, and using IdToken to only interact with the user.


But I'm finding it difficult to explain (show a clear differentiator) 
when the client should use AT and when they should use IdToken to 
impersonate a user and get a new token (via the token exchange)...


Sergey


Phil


On Aug 4, 2016, at 6:00 AM, Mike Schwartz  wrote:

Sergey,

Since no one answered your question, let me pose a few questions to your 
questions!

Wouldn't it give you more flexibility to issue a different token to
represent access to the RS API? In terms of passing user claims,
couldn't this be done via parameters in the API? Are you trying to do
more with OpenID Connect than was anticpiated in the design?
The id_token has an audience, are you including more than one client in that
audience? Would it make sense to look at token exchange and downscope the token?
If you are looking for a profile of OAuth2, might UMA work?

I think you're not alone in wondering what the answer to all these questions 
are..

- Mike


-
Michael Schwartz
Gluu
http://gluu.org


Message: 3
Date: Wed, 3 Aug 2016 11:08:29 +0100
From: Sergey Beryozkin 
To: "oauth@ietf.org" 
Subject: [OAUTH-WG] Using IdToken instead of Access token
Message-ID: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi All
I hope this question is better suited for this list. Will have no
problems redirecting it to the openid-connect list instead.
Consider a user working with the client web application (OIDC RP) which
authenticates the user with the OIDC authorization code flow at the end
of which the client gets AccessToken + IdToken. Next the user requests
something from the client which needs to access the RS to complete this
request.
And the idea is to have the client pass IdToken to RS and use various
user claims inside this IdToken to enforce the access control at the RS
level. My position it is likely wrong but I guess I may be missing
something that will be either in favor or against it.
The reason I think it is wrong is that if the client is using a code
flow then the right approach for staying within the OAuth2 'world' is to
use the access token to talk to RS and use IdToken only for the purpose
of interacting with the user. The access token represents a proper user
authorization and can have the extra scopes in addition to "oidc" which
RS can depend upon in its access control restrictions.
Next I'm arguing that if the IdToken is used instead then it is the case
of the client impersonating the user. And refer to the STS for the REST
of Us draft (I have a separate series of question on that draft). I'm
saying the impersonation can work but ignoring the access tokens
completely will make the overall solution much less flexible.
I'd like to ask for some advice/guidance:
- Is it a good idea at all for the client to use IdToken instead of
AccessToken as explored above ? I suppose it can work, in the code flow
the client gets the access token which, by default, only allows to
access UserInfo. Perhaps the client impersonating IdToken for the
purpose of accessing RS is not too bad after all.
- Assuming the impersonation is OK, what is the right criteria for the
client to choose to work with IdToken instead of the access token when
accessing the immediate RS. It seems like if the impersonation is OK for
the client to do then why have access tokens at all...
- Assuming the impersonation is OK, does STS For the REST of Us shows
the right and the only way it needs to be done ? I can imagine how it
will work for the web app clients, but what about Implici

Re: [OAUTH-WG] Using IdToken instead of Access token

[Sergey Beryozkin]

Hi Mike

On 04/08/16 14:00, Mike Schwartz wrote:

Sergey,

Since no one answered your question, let me pose a few questions to your
questions!

Wouldn't it give you more flexibility to issue a different token to
represent access to the RS API?


If you refer to the fact that in the code flow the client gets both 
AccessToken and IdToken with the former to be used to access the RS API 
then indeed this is what I'm advocating.


But I see in our internal discussions that the desire to use IdToken 
instead is strong and I'm finding I'm lacking some arguments to explain 
why using AT should be preferable and when the user impersonation by the 
client is acceptable then what is the right way to do it (I think it is 
the token exchange draft, the impersonation case).



In terms of passing user claims,
couldn't this be done via parameters in the API?

No

Are you trying to do
more with OpenID Connect than was anticpiated in the design?
This is what I'm saying that OIDC is primarily about the client 
authenticating the user and the access token returned as part of the 
OIDC code flow can be used by the client to continue working with the 
chained RSs on behalf of this user

The id_token has an audience, are you including more than one client in
that
audience? Would it make sense to look at token exchange and downscope
the token?

Yes, I suppose this is what we should do

If you are looking for a profile of OAuth2, might UMA work?

Haven't thought about it yet


I think you're not alone in wondering what the answer to all these
questions are..

Thanks, Sergey


- Mike


-
Michael Schwartz
Gluu
http://gluu.org


Message: 3
Date: Wed, 3 Aug 2016 11:08:29 +0100
From: Sergey Beryozkin 
To: "oauth@ietf.org" 
Subject: [OAUTH-WG] Using IdToken instead of Access token
Message-ID: 
Content-Type: text/plain; charset=windows-1252; format=flowed

Hi All

I hope this question is better suited for this list. Will have no
problems redirecting it to the openid-connect list instead.

Consider a user working with the client web application (OIDC RP) which
authenticates the user with the OIDC authorization code flow at the end
of which the client gets AccessToken + IdToken. Next the user requests
something from the client which needs to access the RS to complete this
request.

And the idea is to have the client pass IdToken to RS and use various
user claims inside this IdToken to enforce the access control at the RS
level. My position it is likely wrong but I guess I may be missing
something that will be either in favor or against it.

The reason I think it is wrong is that if the client is using a code
flow then the right approach for staying within the OAuth2 'world' is to
use the access token to talk to RS and use IdToken only for the purpose
of interacting with the user. The access token represents a proper user
authorization and can have the extra scopes in addition to "oidc" which
RS can depend upon in its access control restrictions.

Next I'm arguing that if the IdToken is used instead then it is the case
of the client impersonating the user. And refer to the STS for the REST
of Us draft (I have a separate series of question on that draft). I'm
saying the impersonation can work but ignoring the access tokens
completely will make the overall solution much less flexible.

I'd like to ask for some advice/guidance:

- Is it a good idea at all for the client to use IdToken instead of
AccessToken as explored above ? I suppose it can work, in the code flow
the client gets the access token which, by default, only allows to
access UserInfo. Perhaps the client impersonating IdToken for the
purpose of accessing RS is not too bad after all.

- Assuming the impersonation is OK, what is the right criteria for the
client to choose to work with IdToken instead of the access token when
accessing the immediate RS. It seems like if the impersonation is OK for
the client to do then why have access tokens at all...

- Assuming the impersonation is OK, does STS For the REST of Us shows
the right and the only way it needs to be done ? I can imagine how it
will work for the web app clients, but what about Implicit Clients.

Many thanks, Sergey





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Using IdToken instead of Access token

[Sergey Beryozkin]

Hi All

I hope this question is better suited for this list. Will have no 
problems redirecting it to the openid-connect list instead.


Consider a user working with the client web application (OIDC RP) which 
authenticates the user with the OIDC authorization code flow at the end 
of which the client gets AccessToken + IdToken. Next the user requests 
something from the client which needs to access the RS to complete this 
request.


And the idea is to have the client pass IdToken to RS and use various 
user claims inside this IdToken to enforce the access control at the RS 
level. My position it is likely wrong but I guess I may be missing 
something that will be either in favor or against it.


The reason I think it is wrong is that if the client is using a code 
flow then the right approach for staying within the OAuth2 'world' is to 
use the access token to talk to RS and use IdToken only for the purpose 
of interacting with the user. The access token represents a proper user 
authorization and can have the extra scopes in addition to "oidc" which 
RS can depend upon in its access control restrictions.


Next I'm arguing that if the IdToken is used instead then it is the case 
of the client impersonating the user. And refer to the STS for the REST 
of Us draft (I have a separate series of question on that draft). I'm 
saying the impersonation can work but ignoring the access tokens 
completely will make the overall solution much less flexible.


I'd like to ask for some advice/guidance:

- Is it a good idea at all for the client to use IdToken instead of 
AccessToken as explored above ? I suppose it can work, in the code flow 
the client gets the access token which, by default, only allows to 
access UserInfo. Perhaps the client impersonating IdToken for the 
purpose of accessing RS is not too bad after all.


- Assuming the impersonation is OK, what is the right criteria for the 
client to choose to work with IdToken instead of the access token when 
accessing the immediate RS. It seems like if the impersonation is OK for 
the client to do then why have access tokens at all...


- Assuming the impersonation is OK, does STS For the REST of Us shows 
the right and the only way it needs to be done ? I can imagine how it 
will work for the web app clients, but what about Implicit Clients.


Many thanks, Sergey

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

[Sergey Beryozkin]

Derek
 >>
 >> ___
 >> OAuth mailing list
 >>OAuth@ietf.org <mailto:OAuth@ietf.org>
 >>https://www.ietf.org/mailman/listinfo/oauth

<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d>
 >
 > ___
 > OAuth mailing list
 >OAuth@ietf.org <mailto:OAuth@ietf.org>
 >https://www.ietf.org/mailman/listinfo/oauth

<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d>

___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d>


___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d>

___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c81244957f086491ed84508d362d07a2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ApH6%2fbRs21OYURWWYx4N4lWVSeCI%2fAPj2eSOA3fdcTw%3d>

___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c81244957f086491ed84508d362d07a2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ApH6%2fbRs21OYURWWYx4N4lWVSeCI%2fAPj2eSOA3fdcTw%3d>



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Sergey Beryozkin

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Regarding using resource indicator to solve resource config issue

[Sergey Beryozkin]

Hi
On 12/04/16 16:58, Phil Hunt (IDM) wrote:

John's assertion that RI can be used to detect mis-configured clients would 
make it mandatory.

This is an AS + RS decision, right (make the tokens bound to specific 
RSs only) ? So if the client wants to access RS with (from now on) 
stronger security restrictions then it is up to the client to ensure it 
can do so.
Yes, if the client does not have this property (directly or indirectly) 
available then it won't be able to access RS but I'm not sure it 
qualifies as breaking the existing clients. (similarly, if the server 
updates its server certificate then the client should be made aware of 
it, etc)...



To avoid that we need a config time solution for misconfiguration.

How about setting the property at the AS Client registration process 
time ? Or updating the existing client's registrations to ensure the 
existing clients can stay operational ?


Cheers, Sergey



Phil


On Apr 12, 2016, at 01:30, Sergey Beryozkin  wrote:

Hi

On 11/04/16 23:19, Phil Hunt (IDM) wrote:
I am objecting to modifying the protocol in the default case as a
majority do not need RI in the case of fixed endpoints.

Migration would be challenging because the change is breaking and
affects existing clients.

How does it break the existing clients given this is an optional feature ? Can 
you please describe the situation where the existing clients get broken ?

Brian, would it make sense to update the text to mention that the clients do 
not have to be directly configured and instead it can be set during the 
registration time, so that the property gets seamlessly linked to client access 
tokens, etc, without the client applications having to be set up with the 
resource indicators manually ?

Thanks, Sergey


Dynamic discovery are up and coming cases and a relatively green field.
Dealing with it at configuration/discovery makes broader sense as it has
no impact on existing clients.

Phil

On Apr 11, 2016, at 12:18, Brian Campbell mailto:bcampb...@pingidentity.com>> wrote:


I'm not sure where the idea that it's only applicable to special uses
like collaboration services is coming from. The pattern described in
the draft (using a different parameter name but otherwise the same) is
deployed and in-use for normal OAuth cases including and especially
the resource owner centric ones.


On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
mailto:phil.h...@oracle.com>> wrote:

I am finding I am not happy with solving the bad resource endpoint
config issue with resource indicator. At best I see this as a
special use draft for things like collab services or things which
aren't resource owner centric.

Yet resource endpoint config is a concern for all clients that
configure on the fly. Is it reasonable to make resource indicator
mandatory for all clients? Probably not.

As OAuth depends primarily on TLS, it feels wrong not to have a
solution that confirms the server host names are correct either
via config lookup or some other mechanism.

Tokbind is also a solution but I suspect it may only appeal to
large scale service providers and may be further off as we wait
for load balancers to support tokbind. Also there are issues with
tokbind on initial user binding where the mitm attack might itself
establish its own token binding. I have to think this through some
to confirm. But the issue of worry is what is happening on
initialization and first use if the hacker has already interceded
a mitm. That would make validation at config time still critical.

Hopefully somebody can arrive at an alternative for broader oauth
use cases.

Phil
___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
Sergey Beryozkin

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





--
Sergey Beryozkin

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Regarding using resource indicator to solve resource config issue

[Sergey Beryozkin]

Hi
On 11/04/16 23:19, Phil Hunt (IDM) wrote:

I am objecting to modifying the protocol in the default case as a
majority do not need RI in the case of fixed endpoints.

Migration would be challenging because the change is breaking and
affects existing clients.

How does it break the existing clients given this is an optional feature 
? Can you please describe the situation where the existing clients get 
broken ?


Brian, would it make sense to update the text to mention that the 
clients do not have to be directly configured and instead it can be set 
during the registration time, so that the property gets seamlessly 
linked to client access tokens, etc, without the client applications 
having to be set up with the resource indicators manually ?


Thanks, Sergey


Dynamic discovery are up and coming cases and a relatively green field.
Dealing with it at configuration/discovery makes broader sense as it has
no impact on existing clients.

Phil

On Apr 11, 2016, at 12:18, Brian Campbell mailto:bcampb...@pingidentity.com>> wrote:


I'm not sure where the idea that it's only applicable to special uses
like collaboration services is coming from. The pattern described in
the draft (using a different parameter name but otherwise the same) is
deployed and in-use for normal OAuth cases including and especially
the resource owner centric ones.


On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
mailto:phil.h...@oracle.com>> wrote:

I am finding I am not happy with solving the bad resource endpoint
config issue with resource indicator. At best I see this as a
special use draft for things like collab services or things which
aren't resource owner centric.

Yet resource endpoint config is a concern for all clients that
configure on the fly. Is it reasonable to make resource indicator
mandatory for all clients? Probably not.

As OAuth depends primarily on TLS, it feels wrong not to have a
solution that confirms the server host names are correct either
via config lookup or some other mechanism.

Tokbind is also a solution but I suspect it may only appeal to
large scale service providers and may be further off as we wait
for load balancers to support tokbind. Also there are issues with
tokbind on initial user binding where the mitm attack might itself
establish its own token binding. I have to think this through some
to confirm. But the issue of worry is what is happening on
initialization and first use if the hacker has already interceded
a mitm. That would make validation at config time still critical.

Hopefully somebody can arrive at an alternative for broader oauth
use cases.

Phil
___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Sergey Beryozkin

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt

[Sergey Beryozkin]

Hi

Is there any reason why 'resource' parameter can not be named 'aud' or 
'audience' ?


The text says "AS should audience restrict" the access token and that a 
token 'aud' property may be equal to this "resource" value.


I guess 'audience' is a pure access token property, while as far as 
client is concerned, it is a 'resource', but I wonder if it would be a 
bit simpler if only a single property was used.


It also might make sense to mention that the clients can have 'resource' 
values associated with them at the registration time - this can be done 
by admins, and the client applications will not have to be configured to 
send 'resource' given that AS already knows about the resource restrictions.


Cheers, Sergey



On 21/03/16 23:15, Phil Hunt wrote:

What about server processing rules and error conditions?  The client
passes the resource in with every request. What happens if it sends a
bad URL.  I see the registration for invalid_resource, but I see no
processing logic for the server that describes when that is returned.
  I’ll assume that is TBD.

The draft seems more finer grained than with bound configuration
approach.  It suggests that the client will make a different URL request
for each resource URL. This could lead to a lot of unnecessary
authorizations.  I think we still have to resolve the audience to
resource relationship problem and just how much detail the AS service
needs to know.

I note that we have a similar issue with bound config on how granular
resource URL processing is needed.  My main goal is for config to
validate the domain name only as a major improvement as we just need to
make sure the client is talking to a valid server and not a MITM proxy.

Finally, there is the question of optionality (in order to have
backwards compatibility for static clients). If resource is optional,
than how do we deal with dynamic clients that simply don’t both to use
the resource parameter?

We’re depending on client developers taking an extra step to provide the
resource parameter. Maybe optionality for resource url becomes part of
the client_id registration?  In contrast, config discovery is brand new,
so making validation required is not such a big deal as static clients
wouldn’t use discovery.

Another failure condition both drafts should consider:
* when an authorization, token, or resource endpoint starts to fail,
should the client fall back to discovery to re-verify configuration?  If
so, on what errors?  A valid usecase would be a service provider
deciding to re-configure its services naturally over time.
* what are the issues when an endpoint that was part of configuration
issues a re-direct? There are good and bad scenarios (e.g. to a specific
cluster node), a resource that was relocated, or a hacked service that
wants to steal tokens.  In these cases, should the client re-validate
the new resource URI either using this draft or the bound config method?

*On a positive note, unrelated to security, there have been a lot of
inquiries over the years about how to authorize against on user-owned
resources.  E.g. How can I ask for authorizations to Brian’s github
project?  I think this is worth discussing.  Weighing the security and
functionality needs would be a worthwhile discussion in BA.*

Phil

@independentid
www.independentid.com 
phil.h...@oracle.com 






On Mar 21, 2016, at 10:41 AM, Brian Campbell
mailto:bcampb...@pingidentity.com>> wrote:

Very minor update to this draft before the deadline that moves Hannes
from Acknowledgements to Authors in acknowledgment of his similar work
a few years ago. Also fleshed out the IANA section with the formal
registration requests.


-- Forwarded message --
From: ** mailto:internet-dra...@ietf.org>>
Date: Mon, Mar 21, 2016 at 11:31 AM
Subject: New Version Notification for
draft-campbell-oauth-resource-indicators-01.txt
To: Hannes Tschofenig mailto:hannes.tschofe...@gmx.net>>, Hannes Tschofenig
mailto:hannes.tschofe...@gmx.net>>, Brian
Campbell mailto:brian.d.campb...@gmail.com>>, John Bradley mailto:ve7...@ve7jtb.com>>



A new version of I-D, draft-campbell-oauth-resource-indicators-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:   draft-campbell-oauth-resource-indicators
Revision:   01
Title:  Resource Indicators for OAuth 2.0
Document date:  2016-03-21
Group:  Individual Submission
Pages:  8
URL:
https://www.ietf.org/internet-drafts/draft-campbell-oauth-resource-indicators-01.txt
Status:
https://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
Htmlized:
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-campbell-oauth-resource-indicators-01

Abstract:
   This straw-man specification defines an extension to The OAuth 2.0
   Authorization Framework that enables the client and authorization
   ser

Re: [OAUTH-WG] Client Credentials flow and Client Registrations

[Sergey Beryozkin]

Sorry,
On 15/03/16 17:51, Sergey Beryozkin wrote:

Hi Justin

AFAIK many Java JAAS systems, etc have things like "username",
"password" set in various properties files, etc, and often these are
really "client_id", "client_secret" in that these are not meant to
support  a direct authentication between some command line client and
this server.

Was actually trying to say above "are meant to"


I understand that if say I had a user working with some server, the user
has authenticated, then the server does some outbound call on behalf of
this user, then it is the impersonation, and I'd plan to use client
credentials here but rather user a code flow. STS for the REST of us
seems to be to support different cases...


Many Thanks
Sergey

On 15/03/16 15:29, Justin Richer wrote:

So long as you’re storing the client_id and client_secret in your LDAP
and not putting a username and password (that normally represents a
person) into the software, you’re fine. That’s just a case of
externalizing the client registration to the LDAP system — it’s still
registered.

Otherwise, if you’re putting a person’s information into the client
there, you’re doing impersonation. That’s bad, don’t do that.

  — Justin


On Mar 15, 2016, at 9:17 AM, Sergey Beryozkin 
wrote:

Hi Justin

Many thanks for the quick response.
On 15/03/16 12:53, Justin Richer wrote:

Is Alice the client here (the piece of software), or is Alice the
resource owner?

Piece of software, something that needs to run without the human user
being involved

If Alice is the resource owner, then you should
absolutely not be using the client credentials flow like this.


Sure.


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.


I guess I'm still OK here, as I said, it is a piece of software which
runs without a user. Like in all web services (SOAP or plain HTTP
client invocations) where the client sets some credentials and
accesses some data in the remote service.


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.


+1

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.

Sure, I understand.

So, as far as my original question is concerned, given that a client
piece of software (no human user is involved) uses some credentials
to get the token with client_credentials, would it be OK to avoid the
explicit 'Client' registration with AS, given that the authentication
system employed by AS is already aware of such credentials, I guess yes.

Thanks, Sergey


  -- 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
OAu

Re: [OAUTH-WG] Client Credentials flow and Client Registrations

[Sergey Beryozkin]

Hi Justin

AFAIK many Java JAAS systems, etc have things like "username", 
"password" set in various properties files, etc, and often these are 
really "client_id", "client_secret" in that these are not meant to 
support  a direct authentication between some command line client and 
this server.


I understand that if say I had a user working with some server, the user 
has authenticated, then the server does some outbound call on behalf of 
this user, then it is the impersonation, and I'd plan to use client 
credentials here but rather user a code flow. STS for the REST of us 
seems to be to support different cases...



Many Thanks
Sergey

On 15/03/16 15:29, Justin Richer wrote:

So long as you’re storing the client_id and client_secret in your LDAP and not 
putting a username and password (that normally represents a person) into the 
software, you’re fine. That’s just a case of externalizing the client 
registration to the LDAP system — it’s still registered.

Otherwise, if you’re putting a person’s information into the client there, 
you’re doing impersonation. That’s bad, don’t do that.

  — Justin


On Mar 15, 2016, at 9:17 AM, Sergey Beryozkin  wrote:

Hi Justin

Many thanks for the quick response.
On 15/03/16 12:53, Justin Richer wrote:

Is Alice the client here (the piece of software), or is Alice the
resource owner?

Piece of software, something that needs to run without the human user being 
involved

If Alice is the resource owner, then you should
absolutely not be using the client credentials flow like this.


Sure.


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.


I guess I'm still OK here, as I said, it is a piece of software which runs 
without a user. Like in all web services (SOAP or plain HTTP client 
invocations) where the client sets some credentials and accesses some data in 
the remote service.


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.


+1

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.

Sure, I understand.

So, as far as my original question is concerned, given that a client piece of 
software (no human user is involved) uses some credentials to get the token 
with client_credentials, would it be OK to avoid the explicit 'Client' 
registration with AS, given that the authentication system employed by AS is 
already aware of such credentials, I guess yes.

Thanks, Sergey


  -- 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___

Re: [OAUTH-WG] When does RS not require token introspection ?

[Sergey Beryozkin]

Hi Thomas

Yes, we currently only support 'small' tokens with the introspection and 
the local caching (though not time but size based which is not ideal if 
we talk about the revocations, though in a high end servers that should 
still invalidate the cache fast enough).
But that does not support multiple AS (I haven't had such a requirement 
but it is an important thing to know about), so a 'light-weight' hybrid 
JWS as it was suggested by several experts seems like a neat compromise.


Sergey
On 15/03/16 16:34, Thomas Broyer wrote:



On Tue, Mar 15, 2016 at 2:02 PM Sergey Beryozkin mailto:sberyoz...@gmail.com>> 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 ?


Because you want to know whether it's been revoked before its
expiration. Introspection is the only way (unless AS and RS are
colocated), as only the AS knows.

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.


If the token is not valid (bad issuer, bad signature, expired; or if the
scopes are included: insufficient scopes), it saves you a request to the
introspection endpoint ;-)
Only if the token passes the first checks would you introspect it to see
if it's still active (not revoked) and possibly retrieve more data about 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.


I think that was the idea yes (didn't someone commented on the thread
that they deployed JWT tokens with shared secrets or symmetric keys?)

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.


As Justin mentioned in the other thread: introspection is useful
(required?) for checking the "liveness" of the token.

Side-note: given the size of a JWT compared to some "simpler", opaque
tokens (mere identifiers), and the fact introspection response are
likely to be cached for a few minutes by the RS, I wonder if using a JWT
so you can possibly avoid an introspection request outweights (sic!) the
bloat of a JWT sent repeatedly over the network (possibly a network with
high latency, low bandwidth, and sometimes paid based on exchanged volumes).
This is rhetoric actually: I side on the "small token that require
introspection" until someone comes with a compelling argument to go the
other way.



--
Sergey Beryozkin

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] When does RS not require token introspection ?

[Sergey Beryozkin]

Hi Justin

I guess it depends on what the customer requirements are, with the AS 
vendor neutrality being one of the variables - something that we had to 
deal with recently.
Or if the RS stack is flexible in a way that it can be easily adapted to 
work with AS from multiple vendors. I can see how it works.


Thanks, Sergey

On 15/03/16 13:36, Justin Richer wrote:


On 3/15/2016 9:35 AM, Sergey Beryozkin wrote:

Hi Justin

On 15/03/16 13:18, Justin Richer wrote:

And don't forget option 4: look it up in a database because the RS and
AS are in the same box.

Sometimes I feel like I understand OAuth2 and today I'm feeling like
I've no idea  what it is :-).

Are AS and RS meant to be collocated ? I thought it was a demo
situation only :-)

Cheers, Sergey


They're conceptually separate, but they can be served by the same
machine and therefore have trusted, proprietary, back-end communications
between them that don't need to be interoperable. It's not just for
demos, and it's actually one of the most common (if not the most common)
deployment of OAuth 2.

  -- Justin






  -- Justin

On 3/15/2016 9:12 AM, John Bradley wrote:

Access tokens are opaque to the client not the RS.

You have three basic design choices.
1 Use a token that the RS can locally validate.  JWT or SAML are
standard options or you could do your own custom format and use a
HMAC to integrity protect them.  If using astandard token format
this supports multiple AS.

2 Use a completely opaque token and introspect it at a known AS.
This supports one AS

3 Hybrid use a JWT that contains an issuer as the token but with a
single opaque claim that is used as a ID by the AS. The RS receives
the token looks at the issuer and sends the token to the issuer for
introspection.   The  introspection endpoint checks the signature
and looks up the reference to provide the introspection response as
in 2.   This supports multiple AS.

I think Juston was recommending 3 as something he has done.

John B.


On Mar 15, 2016, at 10: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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth








___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] When does RS not require token introspection ?

[Sergey Beryozkin]

Hi Justin

It does help, thanks, I was really meaning to ask whether RS was able to 
parse it or not itself, without getting the external introspection 
support, but using a wrong term, 'opaque' for it :-).



Thanks
Sergey
On 15/03/16 13:33, Justin Richer wrote:

Hi Sergey, one comment inline

On 3/15/2016 9:31 AM, Sergey Beryozkin wrote:

Hi John, Justin
On 15/03/16 13:12, John Bradley wrote:

Access tokens are opaque to the client not the RS.


But only if they are self-contained as in the option 1 below, right ?


No. They're non-opaque to the RS in all cases. In that, the RS needs to
be able to figure out what information the token represents. That
doesn't mean that the RS can *parse* the token, but it needs to be able
to find all associated security info about the token (scopes, users,
clients, expirations) in order to make it work.



You have three basic design choices.
1 Use a token that the RS can locally validate.  JWT or SAML are
standard options or you could do your own custom format and use a
HMAC to integrity protect them.  If using astandard token format this
supports multiple AS.


OK.


2 Use a completely opaque token and introspect it at a known AS. This
supports one AS


OK


3 Hybrid use a JWT that contains an issuer as the token but with a
single opaque claim that is used as a ID by the AS.  The RS receives
the token looks at the issuer and sends the token to the issuer for
introspection.   The introspection endpoint checks the signature and
looks up the reference to provide the introspection response as in
2.   This supports multiple AS.

I think Juston was recommending 3 as something he has done.

Thanks for clarifying it, that was what 'jti' was for I believe, very
interesting, I did not get the first time I read it for sure :-).
But this is a non-interoperable solution, right ? I.e, it depends on a
given AS preparing a token this way, would other AS be able to do it
too ?

Thanks, Sergey


John B.


On Mar 15, 2016, at 10: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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] When does RS not require token introspection ?

[Sergey Beryozkin]

Hi Justin

On 15/03/16 13:18, Justin Richer wrote:

And don't forget option 4: look it up in a database because the RS and
AS are in the same box.
Sometimes I feel like I understand OAuth2 and today I'm feeling like 
I've no idea  what it is :-).


Are AS and RS meant to be collocated ? I thought it was a demo situation 
only :-)


Cheers, Sergey



  -- Justin

On 3/15/2016 9:12 AM, John Bradley wrote:

Access tokens are opaque to the client not the RS.

You have three basic design choices.
1 Use a token that the RS can locally validate.  JWT or SAML are standard 
options or you could do your own custom format and use a HMAC to integrity 
protect them.  If using astandard token format this supports multiple AS.

2 Use a completely opaque token and introspect it at a known AS.  This supports 
one AS

3 Hybrid use a JWT that contains an issuer as the token but with a single 
opaque claim that is used as a ID by the AS.  The RS receives the token looks 
at the issuer and sends the token to the issuer for introspection.   The  
introspection endpoint checks the signature and looks up the reference to 
provide the introspection response as in 2.   This supports multiple AS.

I think Juston was recommending 3 as something he has done.

John B.


On Mar 15, 2016, at 10: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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] When does RS not require token introspection ?

[Sergey Beryozkin]

Hi John, Justin
On 15/03/16 13:12, John Bradley wrote:

Access tokens are opaque to the client not the RS.


But only if they are self-contained as in the option 1 below, right ?

You have three basic design choices.
1 Use a token that the RS can locally validate.  JWT or SAML are standard 
options or you could do your own custom format and use a HMAC to integrity 
protect them.  If using astandard token format this supports multiple AS.


OK.


2 Use a completely opaque token and introspect it at a known AS.  This supports 
one AS


OK


3 Hybrid use a JWT that contains an issuer as the token but with a single 
opaque claim that is used as a ID by the AS.  The RS receives the token looks 
at the issuer and sends the token to the issuer for introspection.   The  
introspection endpoint checks the signature and looks up the reference to 
provide the introspection response as in 2.   This supports multiple AS.

I think Juston was recommending 3 as something he has done.
Thanks for clarifying it, that was what 'jti' was for I believe, very 
interesting, I did not get the first time I read it for sure :-).
But this is a non-interoperable solution, right ? I.e, it depends on a 
given AS preparing a token this way, would other AS be able to do it too ?


Thanks, Sergey


John B.


On Mar 15, 2016, at 10: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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Client Credentials flow and Client Registrations

[Sergey Beryozkin]

Hi John
On 15/03/16 13:05, John Bradley wrote:

I think you may be confusing Client credentials flow with resource owner 
credentials flow.

Sorry, I should've clarified initially, it is a piece of software that 
needs to run without a human user. So I hope it is still client_credentials.



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.

Right, I was about to ask how resource owner credentials can help :-), 
but I guess I'll stay away from it for now.


Thanks, Sergey


John B.


On Mar 15, 2016, at 9: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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Client Credentials flow and Client Registrations

[Sergey Beryozkin]

Hi Justin

Many thanks for the quick response.
On 15/03/16 12:53, Justin Richer wrote:

Is Alice the client here (the piece of software), or is Alice the
resource owner?
Piece of software, something that needs to run without the human user 
being involved

If Alice is the resource owner, then you should
absolutely not be using the client credentials flow like this.


Sure.


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.

I guess I'm still OK here, as I said, it is a piece of software which 
runs without a user. Like in all web services (SOAP or plain HTTP client 
invocations) where the client sets some credentials and accesses some 
data in the remote service.



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.


+1

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.

Sure, I understand.

So, as far as my original question is concerned, given that a client 
piece of software (no human user is involved) uses some credentials to 
get the token with client_credentials, would it be OK to avoid the 
explicit 'Client' registration with AS, given that the authentication 
system employed by AS is already aware of such credentials, I guess yes.


Thanks, Sergey


  -- 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] When does RS not require token introspection ?

[Sergey Beryozkin]

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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Client Credentials flow and Client Registrations

[Sergey Beryozkin]

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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWS Access Token concerns

[Sergey Beryozkin]

Hi All

I inadvertently started a private thread when replying to Vladimir, I 
spotted it only now. Forwarding it back to the list.

Vladimir - many thanks

Sergey

 Forwarded Message 
Subject: Re: [OAUTH-WG] JWS Access Token concerns
Date: Wed, 24 Feb 2016 13:34:47 +0200
From: Vladimir Dzhuvinov 
Organization: Connect2id Ltd.
To: Sergey Beryozkin 

I see, tokens encrypted to self! Yes, that can work pretty well. And you
can still have revocation, by keeping a table or cache of the revoked
tokens (identified by "jti" or hash).

Happy coding!

On 24/02/16 12:35, Sergey Beryozkin wrote:

Hi Vladimir

Yes - it helps :-) I was not really planning to start a 'campaign'
against JWS tokens but rather reacted to the fact that I was able to
see more inside the JWS token on the OAuth2 client side than were
visible in the standard access token response (access_token,
expires_in, etc, with access_token carrying a lot more inside itself).

We are planning to support self-contained tokens but right now I'm
inclined to offer a JWE option only (without JWS) and also a JWS if
needed (of course without sticking the sensitive parts inside of it :-)).

The reason I think a JWE-only option is effective is because I'm not
sure RS needs to do an immediate validation it was issued by a given
AS - it can simply post this JWE token to AS it is linked to and AS,
if it can decrypt it using its private key will tell back, using the
standard introspection response all RS needs to know, no need to share
the encryption key with RS.

Same for JWS tokens. Though not sure how PoP tokens will be validated
- we haven't started using them yet and as far as I recall the
introspection spec is not talking about them.


Cheers, Sergey


On 24/02/16 10:19, Vladimir Dzhuvinov wrote:

RFC 6749 is essentially a framework (it even says it in the title),
which means there are plenty of ways to shoot yourself in the foot :)

If our experience can be of help: The Connect2id server can issue
identifier as well as JWT access tokens, depending on policy.

The JWT is signed by default. There are no claims in it that the client
doesn't know already - subject, client_id, granted scope.

There is also an optional "dat" (data) field if the AS / OP wants to
stick additional data for use by the RS.

If integrators want confidentiality of that "data", the JWT can be
additionally encrypted with a key that is shared between OP and RS
instances. That way the token authenticity can still be verified by RS
after decryption. The encryption key is shared, based on the assumption
that the "data" is shared knowledge between AS / OP and all RS
instances. There haven't been requests from customers to make data
confidential for a specific RS (yet).

Now back to reading more sec papers :) Universe must have a way through
the latest sec issues.

Vladimir

On 24/02/16 11:47, Sergey Beryozkin wrote:

Hi
On 24/02/16 05:07, Vladimir Dzhuvinov wrote:

Hi there,

On 23/02/16 23:35, Sergey Beryozkin wrote:

Hi Vladimir

May be I did not express my query well.
When we talk about the access tokens, it is what OAuth2 access token
service returns to the client - it does not have to be JWT, right ?


No, as long as it can work as a token. That is, allow the RS to
determine whether the client can run the request or not, and be sure
that token (and the associated authorisation) come from the AS.

You've probably looked at the spec:

http://tools.ietf.org/html/rfc6749#section-1.4

http://tools.ietf.org/html/rfc6749#section-7.1


Thanks for your patient explanation, but I'm sorry I was not looking
for that :-), I'd like to believe I've got what access tokens are for
and how they are supposed to be validated :-). I'm sorry, it is my
fault.





It is perfectly fine to return a DB pointer, OAuth2 talks about such
access tokens.

Yes. Identifier (key) based tokens have the effect that revoking them
has an immediate effect, so for high security apps their are optimal.
But processing them on the RS side them takes a network call to the
inspection point.

RSA signed JWTs take on the other hand about 50us to verify.


The client should not care. The client is not supposed to start
processing access_token the way it can process the id_token.
It is only something the client will use when accessing RS and
clearly
the 'plain' bearer tokens are full citizens here.

What I'm saying that in fact a client can easily read a JWS-signed
access token content - today I saw some internal properties of a 3rd
party provider which I'm not sure are meant to be visible to the
client at all.


If that's sensitive information that shouldn't be seen by client or
user, then I suggest you report your finding.


This is what I'm doing here. I've no time engaging with the individual
provider's implementers but rather is trying to ask a question to the
group, how sens

Re: [OAUTH-WG] JWS Access Token concerns

[Sergey Beryozkin]

Hi
On 23/02/16 19:31, Antonio Sanso wrote:

hi Sergey,
just my 2 cents
let’s start from a simple fact that encryption is not authentication. :)

And since then the access tokens are supposed to provide the source 
guarantee to the client ? Can you point to any text somewhere suggesting 
the clients must expect the access tokens be a set of JWT JWS signed 
claims ? (lets put the whole PoP aside for now...)



Now, if the claim sets of a JWS contains only not confidential information JWS 
is enough.

You are right - this is close to what I was asking about. My point is 
that given that a JWS-signed JWT content can be processed as easily as 
Base64 encoded data, the problems will start happening if a given OAuth2 
server inadvertently puts more into this JWT container than it should...


Thanks Sergey


See also inline


On Feb 23, 2016, at 6:15 PM, Sergey Beryozkin  wrote:


Hi

Some OAuth2 providers may return self-contained access tokens which are JWS 
Compact-encoded.
I wonder is it really a good idea and would it not be better to only 
JWE-encrypt the tokens. I'm not sure JWS signing the claims is necessarily 
faster then only encrypting the claims, assuming the symmetric algorithms are 
used in both cases.


JWE algorithms are all AEAD AFAIK so is not only symmetric encryption plus there is 
the content key  "wrap algorithm”.

regards

antonio



For example, my colleague and myself, while dealing with the issue related to 
parsing an access token response from a 3rd party provider were able to easily 
check the content of the JWS-signed access_token by simply submitting an easily 
recognized JWS Compact-formatted value (3 dots) into our JWS reader - we did 
not have to worry about decrypting it neither the fact we did not validate the 
signature mattered.

But access tokens are opaque values as far as the clients are concerned and if 
the introspection is needed then the introspection endpoint does exist for that 
purpose...

Thanks, Sergey



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





--
Sergey Beryozkin

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] JWS Access Token concerns

[Sergey Beryozkin]

Hi

Some OAuth2 providers may return self-contained access tokens which are 
JWS Compact-encoded.
I wonder is it really a good idea and would it not be better to only 
JWE-encrypt the tokens. I'm not sure JWS signing the claims is 
necessarily faster then only encrypting the claims, assuming the 
symmetric algorithms are used in both cases.


For example, my colleague and myself, while dealing with the issue 
related to parsing an access token response from a 3rd party provider 
were able to easily check the content of the JWS-signed access_token by 
simply submitting an easily recognized JWS Compact-formatted value (3 
dots) into our JWS reader - we did not have to worry about decrypting it 
neither the fact we did not validate the signature mattered.


But access tokens are opaque values as far as the clients are concerned 
and if the introspection is needed then the introspection endpoint does 
exist for that purpose...


Thanks, Sergey



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Missing response_type with implicit and code flows on the same path

[Sergey Beryozkin]

Hi

I got it, thanks for clarifying the idea :-)

Thanks, Sergey
On 10/02/16 07:59, Vladimir Dzhuvinov wrote:



On 09/02/16 18:21, Sergey Beryozkin wrote:

Hi Vladimir

Thanks for the response,
On 09/02/16 16:09, Vladimir Dzhuvinov wrote:

Hi Sergey,

Yes, HTTP 400 is one way to handle a missing response_type with a
"universal" authz endpoint.


Indeed, looks like it makes sense

Or, you could encode the error in the query string as well as the
fragment, and redirect back to the client.


I'm not sure if that can be done in a 'universal' endpoint case
because it is not known if a client is running in the implicit context
or code flow context. Though I guess it a client is restricted at the
registration time to run only in the code or implicit flows then it
will provide a hint...


If you set both the query and the fragment you'll take care of both flows :)


Cheers, Sergey


Vladimir


On 09/02/16 16:39, Sergey Beryozkin wrote:

Hi

OAuth2 spec recommends how to deal with a missing response_type, set
an error as a query or fragment parameter, depending on whether it is
the authorization code or implicit flow and redirect.

This implies that authorization code and implicit handlers listen on
different paths, for example,

code: /code
implicit: /implicit

so if a response type is missing the handler will know how to set the
error on the redirect uri, as a query or a fragment.

However, I'd like to have a single handler, example (from the OIDC
core):

"https://server.example.com/authorize";

which will support both the code and implicit flows.

Here, 'response_type' is an obvious hint on what kind of flow is in
process, however, if it is missing, how will a server know how to
report a missing response_type error if it uses a shared "/authorize"
path.

I think in such cases reporting 400 is reasonable. Do you agree ?

Thanks, Sergey

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth








___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Missing response_type with implicit and code flows on the same path

[Sergey Beryozkin]

Hi Vladimir

Thanks for the response,
On 09/02/16 16:09, Vladimir Dzhuvinov wrote:

Hi Sergey,

Yes, HTTP 400 is one way to handle a missing response_type with a
"universal" authz endpoint.


Indeed, looks like it makes sense

Or, you could encode the error in the query string as well as the
fragment, and redirect back to the client.

I'm not sure if that can be done in a 'universal' endpoint case because 
it is not known if a client is running in the implicit context or code 
flow context. Though I guess it a client is restricted at the 
registration time to run only in the code or implicit flows then it will 
provide a hint...


Cheers, Sergey


Vladimir


On 09/02/16 16:39, Sergey Beryozkin wrote:

Hi

OAuth2 spec recommends how to deal with a missing response_type, set
an error as a query or fragment parameter, depending on whether it is
the authorization code or implicit flow and redirect.

This implies that authorization code and implicit handlers listen on
different paths, for example,

code: /code
implicit: /implicit

so if a response type is missing the handler will know how to set the
error on the redirect uri, as a query or a fragment.

However, I'd like to have a single handler, example (from the OIDC core):

"https://server.example.com/authorize";

which will support both the code and implicit flows.

Here, 'response_type' is an obvious hint on what kind of flow is in
process, however, if it is missing, how will a server know how to
report a missing response_type error if it uses a shared "/authorize"
path.

I think in such cases reporting 400 is reasonable. Do you agree ?

Thanks, Sergey

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Sergey Beryozkin

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Missing response_type with implicit and code flows on the same path

[Sergey Beryozkin]

Hi

OAuth2 spec recommends how to deal with a missing response_type, set an 
error as a query or fragment parameter, depending on whether it is the 
authorization code or implicit flow and redirect.


This implies that authorization code and implicit handlers listen on 
different paths, for example,


code: /code
implicit: /implicit

so if a response type is missing the handler will know how to set the 
error on the redirect uri, as a query or a fragment.


However, I'd like to have a single handler, example (from the OIDC core):

"https://server.example.com/authorize";

which will support both the code and implicit flows.

Here, 'response_type' is an obvious hint on what kind of flow is in 
process, however, if it is missing, how will a server know how to report 
a missing response_type error if it uses a shared "/authorize" path.


I think in such cases reporting 400 is reasonable. Do you agree ?

Thanks, Sergey

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-02.txt

[Sergey Beryozkin]

Hi Justin

IMHO it would be useful to consider dropping body hashes and simply 
using JWS filters to convert the body to/from JWS compact or even JSON 
on the fly.
I recall there was some conversation before. People do want to stream 
the data end to end in today's web services. The idea of hashing the 
payload (even if it is arguably a 'small' payload such as 50-60k) won't 
fly in many productions but only in the demos.


JWS Compact is designed to support streaming, and even JWS JSON can do 
the streaming on the way out. Of course the final payload, especially if 
it is JWS compact, won't be easy to analyze when it is on the wire, but 
JWS JSON with base64url disabled can help. The filters will need to 
recreate the original body but it is the same with for ex GZIP.


The headers/queries hash can be linked to the signed body as a JWS 
header and thus protected too...


Not sure if it is convincing...

Cheers, Sergey

On 03/02/16 22:30, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

 Title   : A Method for Signing HTTP Requests for OAuth
 Authors : Justin Richer
   John Bradley
   Hannes Tschofenig
Filename: draft-ietf-oauth-signed-http-request-02.txt
Pages   : 13
Date: 2016-02-03

Abstract:
This document a method for offering data origin authentication and
integrity protection of HTTP requests.  To convey the relevant data
items in the request a JSON-based encapsulation is used and the JSON
Web Signature (JWS) technique is re-used.  JWS offers integrity
protection using symmetric as well as asymmetric cryptography.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-signed-http-request-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Sergey Beryozkin

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] How can client react to access token not-before errors

[Sergey Beryozkin]

Hi

Access tokens (particularly JWT-based) may have a not before property 
set - for example, a token introspection response may report an 'nbf' 
property.


How can a client react to the error related to using the access token 
too early ?


Typically a client would attempt to refresh a token if it has been 
rejected by RS, but in the case of NBF related errors it can become a 
cycle - refresh - get a new token - try it, too early, repeat...


I think for RS reporting 503 with Retry-After, instead of 400/401, would 
be the right way to handle NBF errors.


Thanks, Sergey




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

[Sergey Beryozkin]

Hi

On 27/01/16 17:47, William Denniss wrote:

In our implementation we mostly record grants as per-user,
per-client_id. However, we treat public clients whose identity we can't
verify as ineligible for incremental auth. The reason is if a client is
counterfeiting another client, we don't want to return previous
authorizations (the user should at least have to grant permissions in
the context of this other counterfeiting application).  For a public
client where the return path can be guaranteed by the OS (e.g. Universal
Links on iOS), this rule can be relaxed, so it's more about public
clients whose identity cannot be verified (e.g. custom URI scheme, or
localhost redirect).

I have an idea for how to solve those unverifiable clients too, where
the client would prove its previous authorization grant by providing the
current access token on the new "incremental" authorization request.

For verifiable clients, we have an option to "snowball" tokens and
include previous grants (with the exception of some scopes that need
per-device approval), using the non-standard param
include_granted_scopes
<https://developers.google.com/identity/protocols/OAuth2WebServer#incrementalAuth>.
Such a request results in a new token being issued with potentially
increased scope, we don't automatically increase the scope of previously
issued tokens.

Perhaps this group could consider standardizing Incremental OAuth. There
are valuable lessons & techniques that several people here have learnt
and implemented over the years, as shown by this thread. I might be
willing to put together a draft.


IMHO it would be very useful, +1

Thanks, Sergey





On Wed, Jan 27, 2016 at 9:11 AM, Sergey Beryozkin mailto:sberyoz...@gmail.com>> wrote:

Hi George

Thanks. I think I'll need to spend more time on thinking about the
way it has to be implemented, but I guess one thing I realize is
that using only access tokens as records for this purpose is not
ideal/generic.

That said, it is not clear to me that a per-instance level consent
makes sense only when the dynamic registration is used.

Suppose we have a statically registered client, with the client id
shared between 100 devices or even confidential clients. I'm
actually not sure how realistic it is that the same user works with
more than one device sharing the same id, but assuming it is
possible sometimes, and further, with incremental authentication in
place,

we can have a situation where while working on device1 a user has
approved 'a' while on device2 - scope "b", with both devices sharing
the same client id.

May be I'm making it too complex :-)

Thanks, Sergey

On 27/01/16 16:53, George Fletcher wrote:

My recommendation, like the others, is to store consent by
client_id:user and then try and leverage dynamic client
registration if
instance level consent is needed.

On 1/27/16 11:43 AM, George Fletcher wrote:

Yes, I was thinking mostly of "native apps"... though you
bring up a
good point. It would be great if "installable" web apps could do
dynamic client registration:)  I suppose for a "public"
client that is
loaded onto a device, the "installation" process could
obtain a new
client_id for that instance. Cookies might work, or have the app
generate a unique identifier and use that in conjunction
with the
client_id?

Thanks,
George

On 1/27/16 11:07 AM, Thomas Broyer wrote:



On Wed, Jan 27, 2016 at 1:54 PM George Fletcher
mailto:gffle...@aol.com>
<mailto:gffle...@aol.com <mailto:gffle...@aol.com>>> wrote:

 The difference might be whether you want to store
the scope
 consent by client "instance" vs client_id
application "class".


Correct me if I'm wrong but this only makes sense for
"native apps",
not for web apps, right?
(of course, now with "installable web apps" –e.g.
progressive web
apps–, lines get blurry; any suggestion how you'd do it
then? cookies?)



_______
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth




--
Sergey Beryozkin

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

___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

[Sergey Beryozkin]

Hi George

Thanks. I think I'll need to spend more time on thinking about the way 
it has to be implemented, but I guess one thing I realize is that using 
only access tokens as records for this purpose is not ideal/generic.


That said, it is not clear to me that a per-instance level consent 
makes sense only when the dynamic registration is used.


Suppose we have a statically registered client, with the client id 
shared between 100 devices or even confidential clients. I'm actually 
not sure how realistic it is that the same user works with more than one 
device sharing the same id, but assuming it is possible sometimes, and 
further, with incremental authentication in place,


we can have a situation where while working on device1 a user has 
approved 'a' while on device2 - scope "b", with both devices sharing the 
same client id.


May be I'm making it too complex :-)

Thanks, Sergey

On 27/01/16 16:53, George Fletcher wrote:

My recommendation, like the others, is to store consent by
client_id:user and then try and leverage dynamic client registration if
instance level consent is needed.

On 1/27/16 11:43 AM, George Fletcher wrote:

Yes, I was thinking mostly of "native apps"... though you bring up a
good point. It would be great if "installable" web apps could do
dynamic client registration:)  I suppose for a "public" client that is
loaded onto a device, the "installation" process could obtain a new
client_id for that instance. Cookies might work, or have the app
generate a unique identifier and use that in conjunction with the
client_id?

Thanks,
George

On 1/27/16 11:07 AM, Thomas Broyer wrote:



On Wed, Jan 27, 2016 at 1:54 PM George Fletcher mailto:gffle...@aol.com>> wrote:

The difference might be whether you want to store the scope
consent by client "instance" vs client_id application "class".


Correct me if I'm wrong but this only makes sense for "native apps",
not for web apps, right?
(of course, now with "installable web apps" –e.g. progressive web
apps–, lines get blurry; any suggestion how you'd do it then? cookies?)



_______
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





--
Sergey Beryozkin

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

[Sergey Beryozkin]

Your English is better than mine :-), thanks for the feedback.

Well, I guess it can become quite implementation specific. We keep the 
the list of authorized scopes in the access token record, and if this 
access token can also be refreshed then I guess it can be a long term 
record (as far as preserving the history of the scopes previously 
authorized by a given a user for a given client)...Perhaps this is not 
ideal and may need to be reviewed


Sergey

On 27/01/16 12:02, Thomas Broyer wrote:

As fat as I'm concerned, grant==authorisation (English is not my native
language so forgive me if I'm misusing some words).
When the user clicks the authorize button on the consent screen, we save
the scopes in the database. Tokens are independent from that (except for
the business rules that we don't issue a token for a scope that hasn't
been authorized and will revoke tokens for scopes that the user later
"unauthorizes"), each token has its list of scopes maintained
independently from the list of authorized scopes.


Le mer. 27 janv. 2016 12:17, Sergey Beryozkin mailto:sberyoz...@gmail.com>> a écrit :

Hi,

Many thanks to all who provided the feedback.

As far as the existing token update is concerned I was thinking about it
in the context of the incremental authorization which we haven't
implemented yet so we'll need to review how to handle it later on.

Right now we are only prototyping the code for not challenging the user
with a consent screen if the requested scopes have already been approved
(per a given user + client id combination, and which is a base for
supporting the incremental auth at a next step).

I'm a bit confused about the use of a 'grant' term in your replies.

So consider a confidential client redirecting the user and requesting
some scope, as part of the authorization code flow. The user authorizes
the client and the client gets a code *grant* which is according to the
spec can live for up to *10 min*. The client exchanges this grant for a
token with the token preserving the fact the user has authorized a given
scope for this client. I guess this is all quite common.

Note the code 'grant' has already gone by now, because it was already
used once, withing a 10 mins period, which is another spec requirement.

That is why I'm referring to the existing access token record which can
be used for keeping the track of the scopes approved by a given user for
a given client. This token can be refreshed if needed.

When the user's session with a confidential client's web app has
expired, the user is redirected to authenticate, with some scopes
requested. At this point the record which keeps the approved scopes for
a given user/client is an existing access/refresh token.

This is why I'm confused about the use of the 'grant' term in your
replies. I guess this can be a 'grant' record for keeping the list of
the approved scopes/etc not related to a record representing a transient
authorization code record. But as I said, using the live access/refresh
token info seems reasonable, sorry, may be it is becoming too
implementation specific...

Cheers, Sergey





On 26/01/16 23:03, Justin Richer wrote:
 > In MITREid Connect we track grants per client_id per user, and we
have a
 > separate database object for storing them. I wouldn’t recommend
simply
 > updating an access token that’s already in the wild with more power —
 > that just sounds wrong.
 >
 >   — Justin
 >
 >> On Jan 26, 2016, at 1:57 PM, Thomas Broyer mailto:t.bro...@gmail.com>
 >> <mailto:t.bro...@gmail.com <mailto:t.bro...@gmail.com>>> wrote:
 >>
 >> Fwiw, at Ozwillo, we track grants per user per client_id (we don't
 >> support native apps; only web flows for now), and we don't do
 >> "incremental grants" like Google: if you request scope B and the
user
 >> had only granted scope A, you'll get a token for scope B only.
This is
 >> partly because our tokens are not for our own APIs only, contrary to
 >> Google, so we want to allow clients to get tokens with narrow scopes
 >> so they could have one token per third-party API and prevent rogue
 >> resources from trying to use received tokens at other APIs.
 >>
 >> UI-wise, we tell the user what he already granted to the client, and
 >> even let him grant scopes that the client has pre-registered as
 >> "possibly needed at some time" (through a custom provisioning
 >> protocol), but the issued token is always for the exact scopes that
 >> the client requested 

Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

[Sergey Beryozkin]

Hi,

Many thanks to all who provided the feedback.

As far as the existing token update is concerned I was thinking about it 
in the context of the incremental authorization which we haven't 
implemented yet so we'll need to review how to handle it later on.


Right now we are only prototyping the code for not challenging the user 
with a consent screen if the requested scopes have already been approved 
(per a given user + client id combination, and which is a base for 
supporting the incremental auth at a next step).


I'm a bit confused about the use of a 'grant' term in your replies.

So consider a confidential client redirecting the user and requesting 
some scope, as part of the authorization code flow. The user authorizes 
the client and the client gets a code *grant* which is according to the 
spec can live for up to *10 min*. The client exchanges this grant for a 
token with the token preserving the fact the user has authorized a given 
scope for this client. I guess this is all quite common.


Note the code 'grant' has already gone by now, because it was already 
used once, withing a 10 mins period, which is another spec requirement.


That is why I'm referring to the existing access token record which can 
be used for keeping the track of the scopes approved by a given user for 
a given client. This token can be refreshed if needed.


When the user's session with a confidential client's web app has 
expired, the user is redirected to authenticate, with some scopes 
requested. At this point the record which keeps the approved scopes for 
a given user/client is an existing access/refresh token.


This is why I'm confused about the use of the 'grant' term in your 
replies. I guess this can be a 'grant' record for keeping the list of 
the approved scopes/etc not related to a record representing a transient 
authorization code record. But as I said, using the live access/refresh 
token info seems reasonable, sorry, may be it is becoming too 
implementation specific...


Cheers, Sergey





On 26/01/16 23:03, Justin Richer wrote:

In MITREid Connect we track grants per client_id per user, and we have a
separate database object for storing them. I wouldn’t recommend simply
updating an access token that’s already in the wild with more power —
that just sounds wrong.

  — Justin


On Jan 26, 2016, at 1:57 PM, Thomas Broyer mailto:t.bro...@gmail.com>> wrote:

Fwiw, at Ozwillo, we track grants per user per client_id (we don't
support native apps; only web flows for now), and we don't do
"incremental grants" like Google: if you request scope B and the user
had only granted scope A, you'll get a token for scope B only. This is
partly because our tokens are not for our own APIs only, contrary to
Google, so we want to allow clients to get tokens with narrow scopes
so they could have one token per third-party API and prevent rogue
resources from trying to use received tokens at other APIs.

UI-wise, we tell the user what he already granted to the client, and
even let him grant scopes that the client has pre-registered as
"possibly needed at some time" (through a custom provisioning
protocol), but the issued token is always for the exact scopes that
the client requested in this specific request.
And if all requested scopes have already been granted, then we do a
transparent redirect without showing anything to the user (which is
what most other implementations do too)

Le mar. 26 janv. 2016 19:04, Sergey Beryozkin mailto:sberyoz...@gmail.com>> a écrit :

Hi

I'm not sure if the next question is off topic or too low level,
hopefully not,

When the repeated authorization is skipped or only new scopes are
requested to be authorized as per the incremented auth approach, is it
reasonable to assume that the record that is used to track it all is
actually the existing access token or is totally OIDC implementation
specific ?
I think using the existing token as a record is reasonable because
it is
time scoped and if we do not use the access token for keeping the
track
of the multiple approvals, etc, then one need to introduce one more
record mirroring to some extent the access token...

For example, the user session may have expired but the access
token that
was issued to a client web app on behalf of this user is still active,
so when the user returns and signs in again, and for example, approves
few more scopes, then the existing access token (the record) gets
updated, instead of a new token being created.

If it is reasonable then does it mean the sticky or incremental
    authorization works as long as the access token is available
(refreshable) ?

Sergey




On 19/01/16 09:59, Sergey Beryozkin wrote:
> Hi William
>
> Thanks for the advice. FYI we are also on the way

Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

[Sergey Beryozkin]

Hi

I'm not sure if the next question is off topic or too low level, 
hopefully not,


When the repeated authorization is skipped or only new scopes are 
requested to be authorized as per the incremented auth approach, is it 
reasonable to assume that the record that is used to track it all is 
actually the existing access token or is totally OIDC implementation 
specific ?
I think using the existing token as a record is reasonable because it is 
time scoped and if we do not use the access token for keeping the track 
of the multiple approvals, etc, then one need to introduce one more 
record mirroring to some extent the access token...


For example, the user session may have expired but the access token that 
was issued to a client web app on behalf of this user is still active, 
so when the user returns and signs in again, and for example, approves 
few more scopes, then the existing access token (the record) gets 
updated, instead of a new token being created.


If it is reasonable then does it mean the sticky or incremental 
authorization works as long as the access token is available 
(refreshable) ?


Sergey




On 19/01/16 09:59, Sergey Beryozkin wrote:

Hi William

Thanks for the advice. FYI we are also on the way to supporting the
incremental authorization of scopes - thanks for highlighting the
importance of this process on this list...

Cheers, Sergey
On 19/01/16 03:10, William Denniss wrote:

Agree with Justin, this is pretty common. We support it for re-auth as
well as incremental auth (where the user has already approved scope "a"
and is presented with a request for scopes "a b", they will only need to
approve scope "b").  In fact if you don't do this, then incremental auth
isn't really viable.

Regarding security: don't do this for non-confidential clients where you
can't verify the identity of the app by the redirect (e.g. a localhost
redirect to an installed app).

On Mon, Jan 18, 2016 at 4:44 AM, Sergey Beryozkin mailto:sberyoz...@gmail.com>> wrote:

Hi Justin, thanks for the advice,

Cheers, Sergey

On 18/01/16 11:47, Justin Richer wrote:

Yes, this is common practice. Give the user the option to
remember the
decision. This is known as "trust on first use", or tofu. Our
server,
MITREid Connect, implements this as do many others.



-- Justin

/ Sent from my phone /


     Original message 
From: Sergey Beryozkin mailto:sberyoz...@gmail.com>>
Date: 1/18/2016 5:59 AM (GMT-05:00)
To: oauth@ietf.org <mailto:oauth@ietf.org>
Subject: [OAUTH-WG] Can the repeated authorization of scopes be
avoided ?

Hi All

The question relates to the process of showing the authorization
code/implicit flow consent screen to a user.


I'm discussing with my colleagues the possibility of avoiding
asking the
same user whose session has expired and who is re-authenticating
with AS
which scopes should be approved.

For example, suppose the OAuth2 client redirects a user with the
requested scope 'a'. The user signs in to AS and is shown a
consent
screen asking to approve the 'a' scope. The user approves 'a'
and the
flow continues.

Some time later, when the user's session has expired, the user is
redirected to AS with the same 'a' scope.

Would it be a good idea, at this point, not to show the user the
consent
screen asking to approve the 'a' scope again ? For example, AS
can
persist the fact that a given user has already approved 'a' for
a given
client earlier, so when the user re-authenticates, AS will use
this info
and will avoid showing the consent screen.

That seems to make sense, but I'm wondering, can there be some
security
implications associated with it, any recommendations/advices
will be welcome

Sergey

___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth







___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

[Sergey Beryozkin]

ent ID and its issuer identifier (a value defined in the
OAuth Discovery specification <http://self-issued.info/?p=1496>) so
that the client can verify that it is using a consistent set of
authorization server configuration information, that the client ID
is for that authorization server, and in particular, that the client
is not being confused into sending information intended for one
authorization server to a different one.  Note that these attacks
can only be made against clients that are configured to use more
than one authorization server.

Please give the draft a quick read and provide feedback to the OAuth
working group.  This draft is very much a starting point intended to
describe both the mitigations and the decisions and analysis
remaining before we can be confident in standardizing a solution.
Please definitely read the Security Considerations and Open Issues
sections, as they contain important information about the choices
made and the decisions remaining.

Special thanks go to Daniel Fett (University of Trier), Christian
Mainka (Ruhr-University Bochum), Vladislav Mladenov (Ruhr-University
Bochum), and Guido Schmitz (University of Trier) for notifying us of
the attacks and working with us both on understanding the attacks
and on developing mitigations.  Thanks too to Hannes Tschofenig for
organizing a meeting on this topic last month and to Torsten
Lodderstedt and Deutsche Telekom for hosting the meeting.

The specification is available at:

·http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00

An HTML-formatted version is also available at:

·http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html

   -- Mike

P.S.  This note was also posted at http://self-issued.info/?p=1524
and as @selfissued <https://twitter.com/selfissued>.




___

OAuth mailing list

OAuth@ietf.org <mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth



--

Chief Architect

Identity Services Engineering Work:george.fletc...@teamaol.com 
<mailto:george.fletc...@teamaol.com>

AOL Inc.  AIM:  gffletch

Mobile: +1-703-462-3494   Twitter:http://twitter.com/gffletch

Office: +1-703-265-2544   Photos:http://georgefletcher.photography



_______
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Sergey Beryozkin

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

[Sergey Beryozkin]

Hi Brian

In our own code both authorization code and implicit flow requests can 
accommodate an audience property too.
You are right in the latter case there won't be a separate request to a 
token endpoint hence we are treating what follows after the user has 
authorized the implicit client as if it were a token endpoint request.


Not sure about using the audience property in the code flow but I guess 
it can be useful too - for example, the user may be shown this property, 
and then when the client requests a token and happens to supply an 
audience property alongside the code then this audience will have to 
match the one stored in the code grant data...


Cheers, Sergey

On 20/01/16 22:18, Brian Campbell wrote:

There does seem to be a need to provide the client a means of telling
the AS the place(s) and/or entity(s) where it intends to use the token
it's asking for. And that it's common enough to warrant it's own small
spec. This has come up several times before and I think has some
consensus behind doing it. What needs to happen to move forward?

The concept shows up in these three different drafts (that I know of
anyway):

https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3
has an audience parameter
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3
has an aud parameter
http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1 has
both an audience and a resource resource

All the above apply only to the token request. However, there are ways
of requesting/obtaining access tokens that don't involve the token
endpoint <https://tools.ietf.org/html/rfc6749#section-4.2> so I think it
follows that  the same facility should be available for the
authorization request too.




On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig
mailto:hannes.tschofe...@gmx.net>> wrote:

Hi Sergey,

that's a good question. After this document was published the
functionality had been integrated into the PoP solution document.
Recently, I got feedback that the functionality should be more generic
and it is independent of the PoP work.

So, I guess it is a good time to discuss the needed functionality and
where it should be included.

Ciao
Hannes


    On 01/20/2016 11:25 AM, Sergey Beryozkin wrote:
 > Hi
 >
 > Given that the draft-tschofenig-oauth-audience [1] has expired, I'm
 > wondering if it is still relevant.
 >
 > I know the token introspection response can provide the audience
 > value(s), but the question is really how a client is associated
with a a
 > given audience in the first place. As such [1] may still make
sense, for
 > example, I can think of two options:
 > 1. the client audiences are set out of band during the client
 > registration time and all the tokens issued to that client will be
 > restricted accordingly
 > 2. the client is requesting a specific audience during the grant to
 > token exchange as per [1]
 >
 > I guess 1. is how it is done in practice or is 2. is also a valid
option ?
 >
 >
 > Thanks, Sergey
 >
 >
 > [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00
 >
 > ___
 > OAuth mailing list
 > OAuth@ietf.org <mailto:OAuth@ietf.org>
 > https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

[Sergey Beryozkin]

Hi Hannes,
thanks for supporting it, I agree the audience concept is not tied to 
the PoP work


Cheers, Sergey
On 20/01/16 14:27, Hannes Tschofenig wrote:

Hi Sergey,

that's a good question. After this document was published the
functionality had been integrated into the PoP solution document.
Recently, I got feedback that the functionality should be more generic
and it is independent of the PoP work.

So, I guess it is a good time to discuss the needed functionality and
where it should be included.

Ciao
Hannes


On 01/20/2016 11:25 AM, Sergey Beryozkin wrote:

Hi

Given that the draft-tschofenig-oauth-audience [1] has expired, I'm
wondering if it is still relevant.

I know the token introspection response can provide the audience
value(s), but the question is really how a client is associated with a a
given audience in the first place. As such [1] may still make sense, for
example, I can think of two options:
1. the client audiences are set out of band during the client
registration time and all the tokens issued to that client will be
restricted accordingly
2. the client is requesting a specific audience during the grant to
token exchange as per [1]

I guess 1. is how it is done in practice or is 2. is also a valid option ?


Thanks, Sergey


[1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Status of draft-tschofenig-oauth-audience

[Sergey Beryozkin]

Hi

Given that the draft-tschofenig-oauth-audience [1] has expired, I'm 
wondering if it is still relevant.


I know the token introspection response can provide the audience 
value(s), but the question is really how a client is associated with a a 
given audience in the first place. As such [1] may still make sense, for 
example, I can think of two options:
1. the client audiences are set out of band during the client 
registration time and all the tokens issued to that client will be 
restricted accordingly
2. the client is requesting a specific audience during the grant to 
token exchange as per [1]


I guess 1. is how it is done in practice or is 2. is also a valid option ?


Thanks, Sergey


[1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Question about RFC 7622 (Token Introspection)

[Sergey Beryozkin]

Hi Justin

You mentioned a token expiry policy can be that this token will expire 
after a number of uses, in addition to a standard expiry time check.


Is there a standard mechanism to report to AS the token is being used 
(for the purpose of accessing RS resources) ?
I wonder if an actual token introspection request is sufficient to 
indicate to AS that the given token is being used right now to access RS 
- given that the actual client can now also introspect tokens without 
using them to invoke RS services.


is it up to AS Introspection endpoint to figure out the identity of the 
caller, example, if it knows it is RS then it will increase the usage 
count, if a client - won't ?


Thanks, Sergey
On 18/01/16 16:43, Sergey Beryozkin wrote:

Hi Justin

Sorry I did not copy to the list with my previous response...

That sounds convincing, I was about to suggest that AS may opt not to
report the expiry time simply because it is an optional property, but I
guess that would be just an argument for the sake of the argument :-),
as I guess in practice AS will report the expiry time of the tokens that
actually expire...

Many thanks, Sergey



On 18/01/16 16:28, Justin Richer wrote:

If the AS doesn't include the expiration then that means that the RS
doesn't know anything about the token expiring or not. This can be
caused by:

  1) The token never expiring from a timestamp (could still get revoked
or expire after a number of uses)
  2) The RS not being allowed to know if the token expires

Either way, the RS doesn't know anything about the token expiring or not
and so should treat it as if it hasn't expired since that's all the AS
has told it. An RS trying to second guess the AS response here is going
to get into trouble.

If the token expires "shortly" then there would be an expiration in the
response, if the RS is allowed to know that. There's no interoperability
issue here, still, and a special value wouldn't fix this.

  -- Justin

On 1/18/2016 11:10 AM, Sergey Beryozkin wrote:

Hi

If the only way for AS to indicate the token has expired is not to
report this value, while the other AS does not report the specific
expiry time simply because the expiry property is optional, then RS
working with both of those 2 AS has no way to understand if a given
token expires shortly or never expires at all.

That is why I'm thinking having no special value indicating the token
does not expire is an interoperability issue (the communication
between RS and third-part AS servers)

Thanks, Sergey
On 18/01/16 15:55, Justin Richer wrote:

That's a problem for the RS to figure out in its logs system regardless
of whether you choose a "special" value for non-expiration or not. I
don't see how this changes interoperability.

  -- Justin

On 1/16/2016 4:50 PM, Sergey Beryozkin wrote:

Hi Justin
This is reasonable and it works with the introspection protocol
because the text says 'active' means AS must've checked the token has
not expired, but even so, it is in a 'conflict' with the
interoperability concept.
Consider a simple case where RS wants to log "Client uses access token
with this ID, the token expiry time - this time/never" and some other
RS wants to block the requests with the token which will expire in
less then say 5/10 secs.
When this RS works with one AS - this AS thinks it should not report
the expiry time because it means omitting it indicates the token never
expires. The other AS does not report it because: it either does not
know how to rep a 'never expires' value. The next AS thinks it is not
needed to be reported at all.
What should RS do willing to do the above tasks around the expiry time
do :-) ?

Thanks, Sergey

On 16/01/16 16:14, Justin Richer wrote:

All the values in the token introspection response are optional,
except for “active”. If you don’t have anything to say about a
particular aspect of the token, or can’t say it to the software
that’s asking, then you generally leave it out of the response.

  — Justin


On Jan 16, 2016, at 11:02 AM, Vladimir Dzhuvinov
 wrote:



On 15/01/16 15:47, Sergey Beryozkin wrote:

Hi John

Thanks, looks like it was a last minute change because Introduction
does not explain why would clients want to use the introspection
endpoint to effectively 'unwrap' the opaque token representations.

I have another question. How to report the expiry time in cases
when
the tokens do not expire ? I'm aware of some deployments where
access
tokens are only manually deleted and otherwise would not expire.

Perhaps not reporting the expiry time is equivalent to the token
never
expiring ? Or may be reporting 0 or -1 works ?


The core OAuth 2.0 spec seems to imply the former:

http://tools.ietf.org/html/rfc6749#section-5.1

Using a zero or negative integer may not be a good idea, as
clients may
just take the value as it is and add it to the current sy

Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

[Sergey Beryozkin]

Hi William

Thanks for the advice. FYI we are also on the way to supporting the 
incremental authorization of scopes - thanks for highlighting the 
importance of this process on this list...


Cheers, Sergey
On 19/01/16 03:10, William Denniss wrote:

Agree with Justin, this is pretty common. We support it for re-auth as
well as incremental auth (where the user has already approved scope "a"
and is presented with a request for scopes "a b", they will only need to
approve scope "b").  In fact if you don't do this, then incremental auth
isn't really viable.

Regarding security: don't do this for non-confidential clients where you
can't verify the identity of the app by the redirect (e.g. a localhost
redirect to an installed app).

On Mon, Jan 18, 2016 at 4:44 AM, Sergey Beryozkin mailto:sberyoz...@gmail.com>> wrote:

Hi Justin, thanks for the advice,

Cheers, Sergey

On 18/01/16 11:47, Justin Richer wrote:

Yes, this is common practice. Give the user the option to
remember the
decision. This is known as "trust on first use", or tofu. Our
server,
MITREid Connect, implements this as do many others.



-- Justin

/ Sent from my phone /


     Original message 
From: Sergey Beryozkin mailto:sberyoz...@gmail.com>>
Date: 1/18/2016 5:59 AM (GMT-05:00)
To: oauth@ietf.org <mailto:oauth@ietf.org>
Subject: [OAUTH-WG] Can the repeated authorization of scopes be
avoided ?

Hi All

The question relates to the process of showing the authorization
code/implicit flow consent screen to a user.


I'm discussing with my colleagues the possibility of avoiding
asking the
same user whose session has expired and who is re-authenticating
with AS
which scopes should be approved.

For example, suppose the OAuth2 client redirects a user with the
requested scope 'a'. The user signs in to AS and is shown a consent
screen asking to approve the 'a' scope. The user approves 'a'
and the
flow continues.

Some time later, when the user's session has expired, the user is
redirected to AS with the same 'a' scope.

Would it be a good idea, at this point, not to show the user the
consent
screen asking to approve the 'a' scope again ? For example, AS can
persist the fact that a given user has already approved 'a' for
a given
client earlier, so when the user re-authenticates, AS will use
this info
and will avoid showing the consent screen.

That seems to make sense, but I'm wondering, can there be some
security
implications associated with it, any recommendations/advices
will be welcome

Sergey

___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


_______
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth





--
Sergey Beryozkin

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Question about RFC 7622 (Token Introspection)

[Sergey Beryozkin]

Hi Justin

Sorry I did not copy to the list with my previous response...

That sounds convincing, I was about to suggest that AS may opt not to 
report the expiry time simply because it is an optional property, but I 
guess that would be just an argument for the sake of the argument :-), 
as I guess in practice AS will report the expiry time of the tokens that 
actually expire...


Many thanks, Sergey



On 18/01/16 16:28, Justin Richer wrote:

If the AS doesn't include the expiration then that means that the RS
doesn't know anything about the token expiring or not. This can be
caused by:

  1) The token never expiring from a timestamp (could still get revoked
or expire after a number of uses)
  2) The RS not being allowed to know if the token expires

Either way, the RS doesn't know anything about the token expiring or not
and so should treat it as if it hasn't expired since that's all the AS
has told it. An RS trying to second guess the AS response here is going
to get into trouble.

If the token expires "shortly" then there would be an expiration in the
response, if the RS is allowed to know that. There's no interoperability
issue here, still, and a special value wouldn't fix this.

  -- Justin

On 1/18/2016 11:10 AM, Sergey Beryozkin wrote:

Hi

If the only way for AS to indicate the token has expired is not to
report this value, while the other AS does not report the specific
expiry time simply because the expiry property is optional, then RS
working with both of those 2 AS has no way to understand if a given
token expires shortly or never expires at all.

That is why I'm thinking having no special value indicating the token
does not expire is an interoperability issue (the communication
between RS and third-part AS servers)

Thanks, Sergey
On 18/01/16 15:55, Justin Richer wrote:

That's a problem for the RS to figure out in its logs system regardless
of whether you choose a "special" value for non-expiration or not. I
don't see how this changes interoperability.

  -- Justin

On 1/16/2016 4:50 PM, Sergey Beryozkin wrote:

Hi Justin
This is reasonable and it works with the introspection protocol
because the text says 'active' means AS must've checked the token has
not expired, but even so, it is in a 'conflict' with the
interoperability concept.
Consider a simple case where RS wants to log "Client uses access token
with this ID, the token expiry time - this time/never" and some other
RS wants to block the requests with the token which will expire in
less then say 5/10 secs.
When this RS works with one AS - this AS thinks it should not report
the expiry time because it means omitting it indicates the token never
expires. The other AS does not report it because: it either does not
know how to rep a 'never expires' value. The next AS thinks it is not
needed to be reported at all.
What should RS do willing to do the above tasks around the expiry time
do :-) ?

Thanks, Sergey

On 16/01/16 16:14, Justin Richer wrote:

All the values in the token introspection response are optional,
except for “active”. If you don’t have anything to say about a
particular aspect of the token, or can’t say it to the software
that’s asking, then you generally leave it out of the response.

  — Justin


On Jan 16, 2016, at 11:02 AM, Vladimir Dzhuvinov
 wrote:



On 15/01/16 15:47, Sergey Beryozkin wrote:

Hi John

Thanks, looks like it was a last minute change because Introduction
does not explain why would clients want to use the introspection
endpoint to effectively 'unwrap' the opaque token representations.

I have another question. How to report the expiry time in cases when
the tokens do not expire ? I'm aware of some deployments where
access
tokens are only manually deleted and otherwise would not expire.

Perhaps not reporting the expiry time is equivalent to the token
never
expiring ? Or may be reporting 0 or -1 works ?


The core OAuth 2.0 spec seems to imply the former:

http://tools.ietf.org/html/rfc6749#section-5.1

Using a zero or negative integer may not be a good idea, as
clients may
just take the value as it is and add it to the current system time,
concluding that the token has expired :)


Cheers,

Vladimir




Thanks, Sergey
On 15/01/16 13:32, John Bradley wrote:

Some people wanted the client to be able to use introspection.

The ability to pass a refresh token is a legacy of that.    A RS
would never have a refresh token unless it is acting as a client.
That is correct.

John B.


On Jan 15, 2016, at 5:34 AM, Sergey Beryozkin

wrote:

Hi All,

I'm reviewing RFC 7622 as we are going ahead with implementing it.
I have a question:

1. Token Hint in the introspection request.
The spec mentions 'refresh_token' as one of the possible
values. But
a protected resource does not see a refresh token (ever ?), it is
Access

Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

[Sergey Beryozkin]

Hi Justin, thanks for the advice,

Cheers, Sergey
On 18/01/16 11:47, Justin Richer wrote:

Yes, this is common practice. Give the user the option to remember the
decision. This is known as "trust on first use", or tofu. Our server,
MITREid Connect, implements this as do many others.



-- Justin

/ Sent from my phone /


 Original message ----
From: Sergey Beryozkin 
Date: 1/18/2016 5:59 AM (GMT-05:00)
To: oauth@ietf.org
Subject: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

Hi All

The question relates to the process of showing the authorization
code/implicit flow consent screen to a user.


I'm discussing with my colleagues the possibility of avoiding asking the
same user whose session has expired and who is re-authenticating with AS
which scopes should be approved.

For example, suppose the OAuth2 client redirects a user with the
requested scope 'a'. The user signs in to AS and is shown a consent
screen asking to approve the 'a' scope. The user approves 'a' and the
flow continues.

Some time later, when the user's session has expired, the user is
redirected to AS with the same 'a' scope.

Would it be a good idea, at this point, not to show the user the consent
screen asking to approve the 'a' scope again ? For example, AS can
persist the fact that a given user has already approved 'a' for a given
client earlier, so when the user re-authenticates, AS will use this info
and will avoid showing the consent screen.

That seems to make sense, but I'm wondering, can there be some security
implications associated with it, any recommendations/advices will be welcome

Sergey

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Can the repeated authorization of scopes be avoided ?

[Sergey Beryozkin]

Hi All

The question relates to the process of showing the authorization 
code/implicit flow consent screen to a user.



I'm discussing with my colleagues the possibility of avoiding asking the 
same user whose session has expired and who is re-authenticating with AS 
which scopes should be approved.


For example, suppose the OAuth2 client redirects a user with the 
requested scope 'a'. The user signs in to AS and is shown a consent 
screen asking to approve the 'a' scope. The user approves 'a' and the 
flow continues.


Some time later, when the user's session has expired, the user is 
redirected to AS with the same 'a' scope.


Would it be a good idea, at this point, not to show the user the consent 
screen asking to approve the 'a' scope again ? For example, AS can 
persist the fact that a given user has already approved 'a' for a given 
client earlier, so when the user re-authenticates, AS will use this info 
and will avoid showing the consent screen.


That seems to make sense, but I'm wondering, can there be some security 
implications associated with it, any recommendations/advices will be welcome


Sergey

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Question about RFC 7622 (Token Introspection)

[Sergey Beryozkin]

Ouch, you are right, sorry for the confusion,
Thanks, Sergey
On 15/01/16 14:13, Buhake Sindi wrote:

Hi,

Are you not mistaking this with RFC 7662? :-)

Kind Regards,

Buhake Sindi

On 15 Jan 2016 12:34, "Sergey Beryozkin" mailto:sberyoz...@gmail.com>> wrote:

Hi All,

I'm reviewing RFC 7622 as we are going ahead with implementing it.
I have a question:

1. Token Hint in the introspection request.
The spec mentions 'refresh_token' as one of the possible values. But
a protected resource does not see a refresh token (ever ?), it is
Access Token service which does.
When would a protected resource use a 'refresh_token' hint when
requesting an introspection response ?

Thanks, Sergey


___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth




--
Sergey Beryozkin

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Question about RFC 7622 (Token Introspection)

[Sergey Beryozkin]

Hi John

Thanks, looks like it was a last minute change because Introduction does 
not explain why would clients want to use the introspection endpoint to 
effectively 'unwrap' the opaque token representations.


I have another question. How to report the expiry time in cases when the 
tokens do not expire ? I'm aware of some deployments where access tokens 
are only manually deleted and otherwise would not expire.


Perhaps not reporting the expiry time is equivalent to the token never 
expiring ? Or may be reporting 0 or -1 works ?


Thanks, Sergey
On 15/01/16 13:32, John Bradley wrote:

Some people wanted the client to be able to use introspection.

The ability to pass a refresh token is a legacy of that.A RS would never 
have a refresh token unless it is acting as a client.  That is correct.

John B.


On Jan 15, 2016, at 5:34 AM, Sergey Beryozkin  wrote:

Hi All,

I'm reviewing RFC 7622 as we are going ahead with implementing it.
I have a question:

1. Token Hint in the introspection request.
The spec mentions 'refresh_token' as one of the possible values. But a 
protected resource does not see a refresh token (ever ?), it is Access Token 
service which does.
When would a protected resource use a 'refresh_token' hint when requesting an 
introspection response ?

Thanks, Sergey


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Question about RFC 7622 (Token Introspection)

[Sergey Beryozkin]

Hi All,

I'm reviewing RFC 7622 as we are going ahead with implementing it.
I have a question:

1. Token Hint in the introspection request.
The spec mentions 'refresh_token' as one of the possible values. But a 
protected resource does not see a refresh token (ever ?), it is Access 
Token service which does.
When would a protected resource use a 'refresh_token' hint when 
requesting an introspection response ?


Thanks, Sergey


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Sharing a client_id: is it good or bad ?

[Sergey Beryozkin]

Hi John
On 05/11/15 11:09, Sergey Beryozkin wrote:

Hi John, and Jim

Thanks for the feedback
On 04/11/15 22:20, John Bradley wrote:

For a native app you can have one clientID and no secret (same as
having one secret for all of them) or you can use dynamic client
registration to give each one a separate client_id and secret.

The middle ground is to use PKCE and no client secret.

The client generates a pkce challenge in the authorization request and
then presents the verifier.  You can then use that verifier to place a
identifier for that app instance in the refresh/access tokens.   That
would allow the RS to differentiate between two clients with the same
user on different devices.
That gets you more or less equivalent security, but binds the client
instance to a user/device as part of the authorization flow,  rather
than by creating separate client_id for each instance and managing that.
I guess you meant 'client_secret' in this last sentence as I was just 
about to ask if client_id was not needed when PKCE was used, but

https://tools.ietf.org/html/rfc7636#page-9 clarified my confusion :-)

Thanks, Sergey


It is up to more of a deployer preference on what way to go.


We have a code dealing with the PKCE approach available on the server
side, but I've had a little clue so far :-) about how practical it can
be, thanks for the explanation, I'll have a deeper look, might ask a
couple of questions later on...

I prefer the PKCE route personally,  that requires a real user to be
involved in the flow before the AS needs to store state.   In open
dynamic client registration you can face a denial of service attack by
creating unlimited clients, that is harder to manage.

One thing that will be coming up at the WG meeting today is the
possibility of extending PKCE verification to refresh tokens as well
as there current use with code.  That would move the PKCE and client
registration security even closer together.


Thanks, Sergey


John B.


On Nov 5, 2015, at 1:01 AM, Sergey Beryozkin 
wrote:

Hi All

I'm having a discussion with my colleagues on the pros and cons of
sharing a client_id.

For example, say we have N number of public mobile applications (the
same application package, an application instance on an individual
phone), and one approach is for each of these applications to have
the same client_id.

I've been trying to analyze why it can be bad and the only thing I
can come up with is that there will be no (easy) way to track which
application instance actually accessed a given RS.

Can someone please explain what the pros and cons are of having the
same client_id shared between public client applications.

And what about multiple confidential clients being set up with the
same id/secret. I suspect it is a bad idea but what is main line why
it is a bad idea, lets say it is all done in the protected network,
no chance of the bad clients interfering...



Thanks, Sergey

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth







--
Sergey Beryozkin

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Sharing a client_id: is it good or bad ?

[Sergey Beryozkin]

Hi John, and Jim

Thanks for the feedback
On 04/11/15 22:20, John Bradley wrote:

For a native app you can have one clientID and no secret (same as having one 
secret for all of them) or you can use dynamic client registration to give each 
one a separate client_id and secret.

The middle ground is to use PKCE and no client secret.

The client generates a pkce challenge in the authorization request and then 
presents the verifier.  You can then use that verifier to place a identifier 
for that app instance in the refresh/access tokens.   That would allow the RS 
to differentiate between two clients with the same user on different devices.
That gets you more or less equivalent security, but binds the client instance 
to a user/device as part of the authorization flow,  rather than by creating 
separate client_id for each instance and managing that.

It is up to more of a deployer preference on what way to go.

We have a code dealing with the PKCE approach available on the server 
side, but I've had a little clue so far :-) about how practical it can 
be, thanks for the explanation, I'll have a deeper look, might ask a 
couple of questions later on...

I prefer the PKCE route personally,  that requires a real user to be involved 
in the flow before the AS needs to store state.   In open dynamic client 
registration you can face a denial of service attack by creating unlimited 
clients, that is harder to manage.

One thing that will be coming up at the WG meeting today is the possibility of 
extending PKCE verification to refresh tokens as well as there current use with 
code.  That would move the PKCE and client registration security even closer 
together.


Thanks, Sergey


John B.


On Nov 5, 2015, at 1:01 AM, Sergey Beryozkin  wrote:

Hi All

I'm having a discussion with my colleagues on the pros and cons of sharing a 
client_id.

For example, say we have N number of public mobile applications (the same 
application package, an application instance on an individual phone), and one 
approach is for each of these applications to have the same client_id.

I've been trying to analyze why it can be bad and the only thing I can come up 
with is that there will be no (easy) way to track which application instance 
actually accessed a given RS.

Can someone please explain what the pros and cons are of having the same 
client_id shared between public client applications.

And what about multiple confidential clients being set up with the same 
id/secret. I suspect it is a bad idea but what is main line why it is a bad 
idea, lets say it is all done in the protected network, no chance of the bad 
clients interfering...



Thanks, Sergey

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Sharing a client_id: is it good or bad ?

[Sergey Beryozkin]

Hi All

I'm having a discussion with my colleagues on the pros and cons of 
sharing a client_id.


For example, say we have N number of public mobile applications (the 
same application package, an application instance on an individual 
phone), and one approach is for each of these applications to have the 
same client_id.


I've been trying to analyze why it can be bad and the only thing I can 
come up with is that there will be no (easy) way to track which 
application instance actually accessed a given RS.


Can someone please explain what the pros and cons are of having the same 
client_id shared between public client applications.


And what about multiple confidential clients being set up with the same 
id/secret. I suspect it is a bad idea but what is main line why it is a 
bad idea, lets say it is all done in the protected network, no chance of 
the bad clients interfering...




Thanks, Sergey

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Is authorization challenge always needed in OIDC OAuth2 servers ?

[Sergey Beryozkin]

Hi Justin

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

Cheers, Sergey

On 21/10/15 14:37, Justin Richer wrote:

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
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

_______
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





--
Sergey Beryozkin

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Is authorization challenge always needed in OIDC OAuth2 servers ?

[Sergey Beryozkin]

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token introspection for public clients?

[Sergey Beryozkin]

  specific to the kind of API that’s being served.

Requiring the resource server to authenticate with
the authorization server also allows you to do a few
other useful things. Our implementation, for
example, limits the token information that is
returned to a particular AS. This allows us to have
tokens that can be used in multiple RS’s without
those RS’s ever even knowing the token is powerful
enough to be used elsewhere. It prevents information
about the authorization from leaking to parties who
have no business knowing.

Hope this helps clarify it,
 — Justin


On Jul 19, 2015, at 7:59 PM, Aaron Parecki
mailto:aa...@parecki.com>> wrote:

How are public clients supposed to authenticate if
there is no secret?

Isn't "fishing for valid tokens" just as much of an
issue at the resource server? I don't see how
having the introspection endpoint require client
authentication actually solves the fishing problem
since attackers could just fish against the
resource server. In fact, if the resource server
queries the introspection endpoint to check if
tokens are valid, then that effectively gives an
attacker a way to fish for tokens using the
resource server's credentials.

---
Aaron Parecki
http://aaronparecki.com <http://aaronparecki.com/>

On Sat, Jul 18, 2015 at 10:04 PM Justin Richer
mailto:jric...@mit.edu>> wrote:

Public clients can use the token-based auth
mechanism, can’t they? If you don’t have some
form of authentication on the introspection
endpoint, you end up with a way for people to
anonymously and programmatically fish for valid
token values.

 — Justin


On Jul 19, 2015, at 6:30 AM, Aaron Parecki
mailto:aa...@parecki.com>>
wrote:

The introspection draft states that the
introspection endpoint MUST require
authentication of clients. It mentions either
client authentication (id+secret) or a
separate bearer token.

How are public clients expected to use the
token introspection endpoint? I didn't see a
note in the document about that at all.


Aaron Parecki
aaronparecki.com <http://aaronparecki.com/>
@aaronpk <http://twitter.com/aaronpk>

___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth





___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth





___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth





___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Sergey Beryozkin

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

Blog: http://sberyozkin.blogspot.com

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token introspection for public clients?

[Sergey Beryozkin]

Hi,
I've always thought OAuth2 clients are out of the picture here, except 
that the resource server needs to introspect a client's token and it 
(the resource server) needs to authenticate to the introspection endpoint.
Letting the actual OAuth2 clients (confidential or public ones) also 
introspect the endpoint would indeed conflate the roles, and overload 
the access token response protocol which provides all the info the 
actual client needs to know. The client only need to know the token info 
that lets it talk to the resource server, it does not need to introspect 
it like resource server does in order to make an authorization decision.


+1 to what Justin says...

Cheers, Sergey
On 20/07/15 10:39, Justin Richer wrote:

In OAuth, the token is opaque to the client. Clients in general don’t
need to know the kinds of token information that’s returned from the
introspection endpoint. Clients already get information about scopes and
expiration from the token endpoint, what else do they need? If they need
more information, this should be specified as an extension to the token
endpoint, in my opinion. Note that early drafts of this document
targeted both clients and protected resources, but after discussion with
both implementors and the working group, this was pulled back to just
the resource server because that’s what people are doing with it.

A single piece of software can be both an OAuth client and an OAuth
protected resource, but those are two different roles in the system and
shouldn’t be conflated.

  — Justin


On Jul 20, 2015, at 9:34 AM, William Denniss mailto:wdenn...@google.com>> wrote:

Even if the primary target is the protected resource, is there a
reason to exclude use by clients?

The stated reason for this requirement in the spec is to prevent token
scanning, but there are other ways to prevent that.

On Mon, Jul 20, 2015 at 7:01 AM, Justin Richer mailto:jric...@mit.edu>> wrote:

Because the target isn’t the client, it’s the protected resource.
We’re re-using OAuth’s client credentialing mechanisms
(optionally, you can use whatever you deem necessary), but it’s
not a client that’s doing it. That’s why it was changed to a MUST
— there may be public clients out there (which could also use
RFC7591 to become non-public), but public resource servers don’t
make nearly as much sense.

Additionally, the discussion for this was back in December during
the WGLC, and the time for normative changes to this particular
spec is largely over at this stage.

 — Justin


On Jul 20, 2015, at 12:03 AM, William Denniss
mailto:wdenn...@google.com>> wrote:

I see in earlier drafts that client authentication MUST was a SHOULD.

Why not put it back to a SHOULD, and make these arguments in the
Security Considerations?  By the sound of it in some
implementations there are good reasons for doing client
authentication, but they may not apply to everyone, so do we need
to be so prescriptive?  An error response can be added for
requests the server deems require client authentication.

It wouldn't have to be an all-or-nothing policy choice either, a
server could chose to reject requests from confidential clients
where client authentication is not provided, but accept requests
without client authentication from non-confidential clients.  A
server that has sufficiently high entropy in the tokens, abuse
protection on the endpoint, and is not concerned about an
unrelated party (that happens to have a token intended for a
different party) learning the token metadata, could simply not
require any client authentication at all.

Apart from anything, it is really trivial to support
non-confidential client usage, so why not?  Perhaps there are
some use-cases that will turn up in the future (especially since
as defined the introspection response is extensible). One I can
think of now is debugging: it's useful during development to be
able to inspect the tokens you get back from the AS.

Best,
William


On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer mailto:jric...@mit.edu>> wrote:

In the case of a “public client” using a token, the
authorization is the token that the resource server uses to
call the introspection endpoint, along side the token that it
is introspecting. This is exactly how the UMA protocol works:
the resource server has a “Protection API Token” that it uses
to call several endpoints at the AS, including the
introspection endpoint. In UMA, this PAT is given to the
resource server through a normal OAuth transaction with an
end user who facilitates the RS->AS introduction.

And I think this is all actually a moot point because
*clients* shouldn’t be doing the introspection in the first
place — the whole spec is there to support *resource servers*
introspecting at t

Re: [OAUTH-WG] Token Chaining Use Case

[Sergey Beryozkin]

es in different service
deployments. Even though there is a performance hit in the
additional round trips (as Phil brought up in another thread), in
these cases the desire to have the tokens hold least privilege
access rights (smallest set of scopes per service) outweighed any
performance hit (which was shown to be rather small in practice).

What I want is for the token swap draft to define or use a mechanism
that allows us to do this. I think we can do that pretty easily by
adjusting the token swap syntax and language, and explicitly calling
out the semantic processing portion (the current core of the
document) for what it is: a way for a token issuer to communicate to
a token service specific actions. At a high level, the spec would be
something like:



1. How to swap a token at an AS
   1. Send a request to the token endpoint with a new grant type,
and a token (of any type/format/flavor) on the way in
   2. Get back a new token in a token response
2. Communicating act as / on behalf of semantics via a JWT assertion
   1. How to create (as an AS/RS/client/other issuer) a JWT with
act-as semantics
   2. What to do (as an AS/RS) with a JWT with act-as semantics
   3. How to create a JWT with on-behalf-of semeantics
   4. What to do with a JWT with on-behalf-of-semantics
   5. How to possibly represent these semantics with something other
than a JWT



Section 2 uses the syntax from section 1. Other applications, like
the one I laid out above, can use the syntax from section 1 as well.
This works for structured, unstructured, self-generated,
cross-domain, within-domain, and other tokens.


  — Justin

___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Sergey Beryozkin

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

Blog: http://sberyozkin.blogspot.com

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Sergey Beryozkin]

Hi Brian

I've read the text, I like it is still pure OAuth2, with few extra 
parameters added to the access token request, and a key response 
property being 'access_token' as opposed to 'security_access_token' as 
in the draft-ietf-oauth-token-exchange-01.
It appears draft-campbell-oauth-sts-01 can cover a 
draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) 
property being an original client token but not 100% sure given 
draft-richer-oauth-chain-00 covers a specific case.


One thing I'm not sure about is what is the purpose of specifying a 
security_token_type of the returned access token


Thanks, Sergey

On 01/07/15 15:59, Brian Campbell wrote:

One problem, I think, with token exchange is that it can be really
simple (token in and token out) and really complicated (client X wants a
token that says user A is doing something on behalf of user B) at the
same time.

I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in
an attempt to simplify things and express what I envisioned as an OAuth
based token exchange framework. Though it likely only muddied the waters :)

On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin mailto:sberyoz...@gmail.com>> wrote:

Hi Justin

https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much
easier to read, that I can tell for sure, at least it is obvious why
a given entity (RS1) may want to exchange the current token provided
by a client for a new token. Definitely easily implementable...

One thing I'm not sure in the draft-richer-oauth-chain-00 about is
on behalf of whose entity RS1 will be acting once it starts
accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO +
Client), or may be it is On Behalf Of RO + Act As Client ? The last
one seems most logical to me...

Thanks, Sergey


On 01/07/15 13:18, Justin Richer wrote:

As it's written right now, it's a translation of some WS-*
concepts into
JWT format. It's not really OAuth-y (since the client has to
understand
the token format along with everyone else, and according to the
authors
the artifacts might not even be "OAuth tokens"), and that's my main
issue with the document. Years ago, I proposed an OAuth-based
token swap
mechanism:

https://tools.ietf.org/html/draft-richer-oauth-chain-00

This works without defining semantics of the tokens themselves, just
like the rest of OAuth. I've proposed to the authors of the current
draft that it should incorporate both semantic (using JWT) and
syntactic
(using a simple token-agnostic grant) token swap mechanisms, and
that
the two could be easily compatible.

   -- Justin

On 7/1/2015 6:35 AM, Sergey Beryozkin wrote:

Hmm... perhaps the clue is in the draft title,
token-exchange, so may
be it is a case of the given access token ("on_behalf_of" or
"act_as"
claim) being used to request a new security token. One can
only guess
though, does not seem like the authors are keen to answer
the newbie
    questions...

Cheers, Sergey


On 30/06/15 13:38, Sergey Beryozkin wrote:

Hi,
Can you please explain what is the difference between
On-Behalf-Of
semantics described in the
draft-ietf-oauth-token-exchange-01 and the
implicit On-Behalf-Of semantics a client OAuth2 token
possesses ?

For example, draft-ietf-oauth-token-exchange-01 mentions:

"Whereas, with on-behalf-of semantics, principal A still
has its own
identity separate from B and it is explicitly understood
that while B
may have delegated its rights to A, any actions taken
are being taken by
A and not B. In a sense, A is an agent for B."

This is a typical case with the authorization code flow
where a client
application acts on-behalf-of the user who authorized
this application ?

Sorry if I'm missing something

Cheers, Sergey
On 25/06/15 22:28, Mike Jones wrote:

That’s what

https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01
is
about.

Cheers,

-- Mike

*From:*OAuth [mailto:oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>] *On Behalf Of *Vivek
Biswas
-T (vibiswas - XORI

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Sergey Beryozkin]

Hi Justin

https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much easier 
to read, that I can tell for sure, at least it is obvious why a given 
entity (RS1) may want to exchange the current token provided by a client 
for a new token. Definitely easily implementable...


One thing I'm not sure in the draft-richer-oauth-chain-00 about is on 
behalf of whose entity RS1 will be acting once it starts accessing RS2, 
On Behalf Of RO, or may be On Behalf Of (RO + Client), or may be it is 
On Behalf Of RO + Act As Client ? The last one seems most logical to me...


Thanks, Sergey

On 01/07/15 13:18, Justin Richer wrote:

As it's written right now, it's a translation of some WS-* concepts into
JWT format. It's not really OAuth-y (since the client has to understand
the token format along with everyone else, and according to the authors
the artifacts might not even be "OAuth tokens"), and that's my main
issue with the document. Years ago, I proposed an OAuth-based token swap
mechanism:

https://tools.ietf.org/html/draft-richer-oauth-chain-00

This works without defining semantics of the tokens themselves, just
like the rest of OAuth. I've proposed to the authors of the current
draft that it should incorporate both semantic (using JWT) and syntactic
(using a simple token-agnostic grant) token swap mechanisms, and that
the two could be easily compatible.

  -- Justin

On 7/1/2015 6:35 AM, Sergey Beryozkin wrote:

Hmm... perhaps the clue is in the draft title, token-exchange, so may
be it is a case of the given access token ("on_behalf_of" or "act_as"
claim) being used to request a new security token. One can only guess
though, does not seem like the authors are keen to answer the newbie
questions...

Cheers, Sergey


On 30/06/15 13:38, Sergey Beryozkin wrote:

Hi,
Can you please explain what is the difference between On-Behalf-Of
semantics described in the draft-ietf-oauth-token-exchange-01 and the
implicit On-Behalf-Of semantics a client OAuth2 token possesses ?

For example, draft-ietf-oauth-token-exchange-01 mentions:

"Whereas, with on-behalf-of semantics, principal A still has its own
identity separate from B and it is explicitly understood that while B
may have delegated its rights to A, any actions taken are being taken by
A and not B. In a sense, A is an agent for B."

This is a typical case with the authorization code flow where a client
application acts on-behalf-of the user who authorized this application ?

Sorry if I'm missing something

Cheers, Sergey
On 25/06/15 22:28, Mike Jones wrote:

That’s what
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is
about.

Cheers,

-- Mike

*From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Vivek
Biswas
-T (vibiswas - XORIANT CORPORATION at Cisco)
*Sent:* Thursday, June 25, 2015 2:20 PM
*To:* OAuth@ietf.org
*Subject:* [OAUTH-WG] JWT Token on-behalf of Use case

Hi All,

   I am looking to solve a use-case similar to WS-Security On-Behalf-Of
<http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html#_Toc325658980>


with OAuth JWT Token.

   Is there a standard claim which we can define within the OAuth JWT
which denote the On-behalf-of User.

For e.g., a Customer Representative trying to create token on behalf of
a customer and trying to execute services specific for that specific
customer.

Regards,

Vivek Biswas,
CISSP

*Cisco Systems, Inc <http://www.cisco.com/>*

*Bldg. J, San Jose, USA,*

*Phone: +1 408 527 9176*



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Sergey Beryozkin]

Hmm... perhaps the clue is in the draft title, token-exchange, so may be 
it is a case of the given access token ("on_behalf_of" or "act_as" 
claim) being used to request a new security token. One can only guess 
though, does not seem like the authors are keen to answer the newbie 
questions...


Cheers, Sergey


On 30/06/15 13:38, Sergey Beryozkin wrote:

Hi,
Can you please explain what is the difference between On-Behalf-Of
semantics described in the draft-ietf-oauth-token-exchange-01 and the
implicit On-Behalf-Of semantics a client OAuth2 token possesses ?

For example, draft-ietf-oauth-token-exchange-01 mentions:

"Whereas, with on-behalf-of semantics, principal A still has its own
identity separate from B and it is explicitly understood that while B
may have delegated its rights to A, any actions taken are being taken by
A and not B. In a sense, A is an agent for B."

This is a typical case with the authorization code flow where a client
application acts on-behalf-of the user who authorized this application ?

Sorry if I'm missing something

Cheers, Sergey
On 25/06/15 22:28, Mike Jones wrote:

That’s what
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is about.

 Cheers,

 -- Mike

*From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Vivek Biswas
-T (vibiswas - XORIANT CORPORATION at Cisco)
*Sent:* Thursday, June 25, 2015 2:20 PM
*To:* OAuth@ietf.org
*Subject:* [OAUTH-WG] JWT Token on-behalf of Use case

Hi All,

   I am looking to solve a use-case similar to WS-Security On-Behalf-Of
<http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html#_Toc325658980>

with OAuth JWT Token.

   Is there a standard claim which we can define within the OAuth JWT
which denote the On-behalf-of User.

For e.g., a Customer Representative trying to create token on behalf of
a customer and trying to execute services specific for that specific
customer.

Regards,

Vivek Biswas,
CISSP

*Cisco Systems, Inc <http://www.cisco.com/>*

*Bldg. J, San Jose, USA,*

*Phone: +1 408 527 9176*



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Sergey Beryozkin]

Hi,
Can you please explain what is the difference between On-Behalf-Of 
semantics described in the draft-ietf-oauth-token-exchange-01 and the 
implicit On-Behalf-Of semantics a client OAuth2 token possesses ?


For example, draft-ietf-oauth-token-exchange-01 mentions:

"Whereas, with on-behalf-of semantics, principal A still has its own 
identity separate from B and it is explicitly understood that while B 
may have delegated its rights to A, any actions taken are being taken by 
A and not B. In a sense, A is an agent for B."


This is a typical case with the authorization code flow where a client 
application acts on-behalf-of the user who authorized this application ?


Sorry if I'm missing something

Cheers, Sergey
On 25/06/15 22:28, Mike Jones wrote:

That’s what
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is about.

 Cheers,

 -- Mike

*From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Vivek Biswas
-T (vibiswas - XORIANT CORPORATION at Cisco)
*Sent:* Thursday, June 25, 2015 2:20 PM
*To:* OAuth@ietf.org
*Subject:* [OAUTH-WG] JWT Token on-behalf of Use case

Hi All,

   I am looking to solve a use-case similar to WS-Security On-Behalf-Of

with OAuth JWT Token.

   Is there a standard claim which we can define within the OAuth JWT
which denote the On-behalf-of User.

For e.g., a Customer Representative trying to create token on behalf of
a customer and trying to execute services specific for that specific
customer.

Regards,

Vivek Biswas,
CISSP

*Cisco Systems, Inc *

*Bldg. J, San Jose, USA,*

*Phone: +1 408 527 9176*



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] The best method to get generated bearer tokens encoded

[Sergey Beryozkin]

Hi John

Thanks for the comments, what I'm curious about is not how to get a 
generated (bearer) access token encoded with the encoded value having a 
fewer number of characters but how to better support a security 
requirement that it should be difficult for an attacker to reproduce a 
given access token value...


So I've been wondering if the fact that Base64(URL) has a richer set of 
characters than HEX makes it a better alternative...Not 100% sure how 
important it can be...


Thanks, Sergey

On 07/04/15 14:09, John Bradley wrote:

Best would depend on what you are encoding.  If the thing you are encoding is 
mostly URL safe then using URL escaping might give you the smallest result.
If it is 8bit data then BASE64URL will give you a smaller result than HEX 
encoding.

JWT use BASE64URL as a datapoint.

John B.

On Apr 7, 2015, at 3:58 AM, Sergey Beryozkin  wrote:

Hi

Would it be correct to assume that the best method for encoding the 
auto-generated bearer tokens is Base64URL ? I've spotted recently some of our 
code uses the Hex encoding which I believe is inferior compared to Base64URL 
given that the latter has a richer set of characters.

Is it a correct assumption ?

Thanks, Sergey

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] The best method to get generated bearer tokens encoded

[Sergey Beryozkin]

Hi

Would it be correct to assume that the best method for encoding the 
auto-generated bearer tokens is Base64URL ? I've spotted recently some 
of our code uses the Hex encoding which I believe is inferior compared 
to Base64URL given that the latter has a richer set of characters.


Is it a correct assumption ?

Thanks, Sergey

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Returning tokens directly to a human user

[Sergey Beryozkin]

Hi Justin,

Thanks for typing it all, appreciated... I guess the idea here is 
basically introduce a little web app 'intermediary' that will act as if 
it were a client except that it will show whatever it receives back from 
AS to the user.
So we still have a common processing path at AS, as if it were a regular 
authorization code flow. I think I got it...


Thanks for the advice - enjoy the weekends
Sergey

On 06/03/15 22:47, Justin Richer wrote:



On Mar 6, 2015, at 5:31 PM, Sergey Beryozkin  wrote:

Hi
On 06/03/15 18:28, Justin Richer wrote:

All you’re really doing here is having a more manual and less automated portion 
for part of the process. You’d want to do this using a registered redirect URI 
that hosts the HTML page, and then you’d need a control in the app itself where 
the user could interact.

I would personally recommend using this approach to move an authorization code 
manually instead of moving an access token. Assuming your client can access the 
auth server directly (using the backchannel, no browser), you should be able to 
POST to the token endpoint and get the token directly without the user having 
to handle it. The reason being that auth codes are client-limited and much more 
time-limited, and their leakage doesn’t immediately lead to leakage of API 
access.


Right now this is what I'm considering, whether to restrict it to the client 
getting the tokens itself, with the inserted code, or indirectly, after the 
user does it. We already support the former for public clients, I guess in the 
latter case a token will also be linked to a client because a user will enter a 
client id when requesting a token.

Just not sure yet if a 3rd party client will be 'prepared' as you say to 
interact directly with AS, I guess it will be given that it is expected it 
should be able to refresh…






We had a similar approach with a limited client back in the OAuth 1.0 days, 
where we had an HTML page that would print the oauth_verify code on the screen 
that the user would type into the application. These days, on most platforms, 
it’s much easier to register a custom URL handler or use another system service 
to get the code directly that this hack has all but disappeared, at least in my 
view.


Can you give me a favor and clarify a bit what you mean when referring to a 
registered URL handler ? A user signs in, requests a code or a token for a 
specific client, AS returns it to the user directly. I guess it can redirect 
the user to some other web application which is where the user will interact 
and get the code or token. What a registered URL handler can change in this 
process, make it more automated ? (I understand working with the code is better 
in general…)


I mean not doing anything special with the OAuth grants: use the redirects that 
are already there, just do something special with the page you’re redirected to 
that will display the code/token to the user and instruct them to paste it into 
the client appropriately. It can even be a pretty static page, with a bit of 
javascript to pull off the return values.

So you could build it like this: the user starts off at some webpage that says 
“Authorize AppX” and clicks that. This redirects them to the authorization 
endpoint, just like normal. Note that this redirect will include the client ID 
and scopes and all that, just like normal. Then the user logs in, authorizes, 
and is redirected back to AppX’s redirect_uri, just like normal. This redirect 
URI will be on the same service that hosts the “start off” page, if you want, 
so you can even check the “state” value against a stored cookie or session for 
extra protection. That page pops off the code or token parameter and displays 
it to the user, telling them how to get it into the client. Once the code or 
token is in the client, it goes on its way.

This all works without changing OAuth at all, and the auth server and resource 
server can be completely off-the-shelf. You’re effectively splitting the client 
in half: there’s a web-based half that deals with the authorization redirect, 
and a native half that deals with the code/token swap and the protected API 
calls. You use a person to glue them together.

I’ve built this kind of thing before, and it works well until people fall apart 
moving the displayed code between the web page and the rest of the application. 
That’s why a lot of apps, where possible, have just gone to popping up a 
browser. Dick’s recommendation to look at settop boxes and other apps that 
*can’t* pop up a browser is a good recommendation.

  — Justin




Thanks, Sergey



  — Justin


On Mar 6, 2015, at 12:22 PM, Sergey Beryozkin  wrote:

Hi All,

We might have a requirement to support a case where AS returns an access token 
directly to a human user, with the user subsequently configuring a confidential 
client with this token. The actual client is not capable of supporting a (more 
dynamic) code flow at this stage.

Re: [OAUTH-WG] Returning tokens directly to a human user

[Sergey Beryozkin]

Hi
On 06/03/15 18:28, Justin Richer wrote:

All you’re really doing here is having a more manual and less automated portion 
for part of the process. You’d want to do this using a registered redirect URI 
that hosts the HTML page, and then you’d need a control in the app itself where 
the user could interact.

I would personally recommend using this approach to move an authorization code 
manually instead of moving an access token. Assuming your client can access the 
auth server directly (using the backchannel, no browser), you should be able to 
POST to the token endpoint and get the token directly without the user having 
to handle it. The reason being that auth codes are client-limited and much more 
time-limited, and their leakage doesn’t immediately lead to leakage of API 
access.

Right now this is what I'm considering, whether to restrict it to the 
client getting the tokens itself, with the inserted code, or indirectly, 
after the user does it. We already support the former for public 
clients, I guess in the latter case a token will also be linked to a 
client because a user will enter a client id when requesting a token.


Just not sure yet if a 3rd party client will be 'prepared' as you say to 
interact directly with AS, I guess it will be given that it is expected 
it should be able to refresh...




We had a similar approach with a limited client back in the OAuth 1.0 days, 
where we had an HTML page that would print the oauth_verify code on the screen 
that the user would type into the application. These days, on most platforms, 
it’s much easier to register a custom URL handler or use another system service 
to get the code directly that this hack has all but disappeared, at least in my 
view.


Can you give me a favor and clarify a bit what you mean when referring 
to a registered URL handler ? A user signs in, requests a code or a 
token for a specific client, AS returns it to the user directly. I guess 
it can redirect the user to some other web application which is where 
the user will interact and get the code or token. What a registered URL 
handler can change in this process, make it more automated ? (I 
understand working with the code is better in general...)


Thanks, Sergey



  — Justin


On Mar 6, 2015, at 12:22 PM, Sergey Beryozkin  wrote:

Hi All,

We might have a requirement to support a case where AS returns an access token 
directly to a human user, with the user subsequently configuring a confidential 
client with this token. The actual client is not capable of supporting a (more 
dynamic) code flow at this stage.

So it is nearly like an implicit code flow except that the user is asked 
upfront which clients can get the tokens allocated and the token is returned in 
the HTML response without redirecting and placing the token in a fragment.

Apparently a number of big providers do just that, let users allocate tokens 
for some clients with the users expected to copy the tokens into the 
confidential clients afterwards.

I'd like to ask, it is a reasonable approach, to have tokens transferred 
manually into the confidential client ?

Would it be more appropriate for a user to request a code and then copy it to 
the confidential client and expect it to get the tokens itself. I guess the 
problem here may be a code is short lived, but so is a typical access token - 
but the latter can be supported by a refresh one.

Another question: does it even qualify as an OAuth2 grant for token exchange, 
the process of a user pre-authorizing a client and getting not a code but 
tokens back ? I guess it does, so how a grant like this one would typically be 
called ? We'd have no problems with assigning some custom name to such a grant 
but curious how others approach it...

Thanks, Sergey




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Returning tokens directly to a human user

[Sergey Beryozkin]

Thanks for a reference to such applications...

Sergey
On 06/03/15 18:07, Dick Hardt wrote:

If you are interested in how others have done a similar flow, you could
look at how smart TVs supporting Netflix and Amazon are authorized.

On Fri, Mar 6, 2015 at 9:22 AM, Sergey Beryozkin mailto:sberyoz...@gmail.com>> wrote:

Hi All,

We might have a requirement to support a case where AS returns an
access token directly to a human user, with the user subsequently
configuring a confidential client with this token. The actual client
is not capable of supporting a (more dynamic) code flow at this stage.

So it is nearly like an implicit code flow except that the user is
asked upfront which clients can get the tokens allocated and the
token is returned in the HTML response without redirecting and
placing the token in a fragment.

Apparently a number of big providers do just that, let users
allocate tokens for some clients with the users expected to copy the
tokens into the confidential clients afterwards.

I'd like to ask, it is a reasonable approach, to have tokens
transferred manually into the confidential client ?

Would it be more appropriate for a user to request a code and then
copy it to the confidential client and expect it to get the tokens
itself. I guess the problem here may be a code is short lived, but
so is a typical access token - but the latter can be supported by a
refresh one.

Another question: does it even qualify as an OAuth2 grant for token
exchange, the process of a user pre-authorizing a client and getting
not a code but tokens back ? I guess it does, so how a grant like
this one would typically be called ? We'd have no problems with
assigning some custom name to such a grant but curious how others
approach it...

Thanks, Sergey




_
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/__listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Using refresh tokens to authenticate the clients

[Sergey Beryozkin]

Hi All,

The example at [1] suggests that clients working with a refresh grant 
authenticate as usual when they need to use a grant.


The section 3.3 in the threat model document [2] says that

   "as long as the confidentiality of the particular token can be
   ensured by the client, a refresh token can also be used as an
   alternative means to authenticate the client instance itself"

How this can be processed by the access token service that expects a 
client to authenticate ?

Example, typically,
Authorization: Basic encodedInfo

If a refresh token is used to authenticate, how to express it ?

client_id=refreshToken in the form payload or URI query ?

Thanks, Sergey


[1] https://tools.ietf.org/html/rfc6749#section-6
[2] https://tools.ietf.org/html/rfc6819#section-3.3

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Returning tokens directly to a human user

[Sergey Beryozkin]

Hi All,

We might have a requirement to support a case where AS returns an access 
token directly to a human user, with the user subsequently configuring a 
confidential client with this token. The actual client is not capable of 
supporting a (more dynamic) code flow at this stage.


So it is nearly like an implicit code flow except that the user is asked 
upfront which clients can get the tokens allocated and the token is 
returned in the HTML response without redirecting and placing the token 
in a fragment.


Apparently a number of big providers do just that, let users allocate 
tokens for some clients with the users expected to copy the tokens into 
the confidential clients afterwards.


I'd like to ask, it is a reasonable approach, to have tokens transferred 
manually into the confidential client ?


Would it be more appropriate for a user to request a code and then copy 
it to the confidential client and expect it to get the tokens itself. I 
guess the problem here may be a code is short lived, but so is a typical 
access token - but the latter can be supported by a refresh one.


Another question: does it even qualify as an OAuth2 grant for token 
exchange, the process of a user pre-authorizing a client and getting not 
a code but tokens back ? I guess it does, so how a grant like this one 
would typically be called ? We'd have no problems with assigning some 
custom name to such a grant but curious how others approach it...


Thanks, Sergey




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Confusion on Implicit Grant flow

[Sergey Beryozkin]

Hi John
On 09/02/15 22:59, John Bradley wrote:

The security problem was people only doing host name matching on redirect_uri 
and attackers finding redirectors to use.   That impacted all public clients 
not just implicit.
Implicit took most of the heat because that was what Facebook was using, and 
they had the largest issue.

Connect has a response_mode that allows the response to be form encoded rather 
than fragment.
I read RFC 5849 as only allowing code to be query encoded.   The response_mode 
was intended for the new response types we defined in 
http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html

The spec for response mode is here 
http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html

We haven't done anything with it recently.  I don't know if the OAuth WG wants 
to take it up.

What is your opinion on providing a feature 'symmetric' to the one where 
a signed and/or encrypted code request is passed to AS ? The feature 
would return a signed and/or encrypted code in the redirect URI as usual.


I'm not sure it would help the implicit clients though...Unless the 
encryption key can be derived from a combination of the client_id and 
some extra piece of information encoded in the JS script but also known 
to AS (via the registration, etc)


Thanks, Sergey





John B.

On Feb 9, 2015, at 7:32 PM, Bill Burke  wrote:



On 2/9/2015 5:03 PM, John Bradley wrote:

OK, I don't know if the WG has discussed the issue of fragments in browser 
history.

So you are trading off several round trips against the possibility of a token 
leaking in browser history or bookmark?



Yes, bookmarking tokens is a little scary, IMO, as we've already run into users 
bookmarking URLs with codes in them.

Also, wasn't there additional security vulnerabilities surrounding implicit 
flow?  Maybe these were just the product of incorrect implementations, I don't 
remember, it was a while ago.


One extension that Connect introduced was a "code id_token" response type that 
is fragment encoded.  That would let you pass the code directly to the JS saving two legs.



It looks like OIDC added a "response_mode" parameter where you can specify "query" or 
"fragment".  Thanks for pointing this out!


Thanks for all the help.


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00.txt

[Sergey Beryozkin]

Hi, yes, it is obvious for anyone who has read the text carefully :-),
sorry for the noise
Sergey
On 22/12/14 12:33, Justin Richer wrote:

That's easy: any headers. That's why the signer specifies which ones.
Would be good to have since guidance tough, and examples.


-- Justin

/ Sent from my phone /


 Original message ----
From: Sergey Beryozkin 
Date:12/22/2014 7:08 AM (GMT-05:00)
To: oauth@ietf.org
Cc:
Subject: Re: [OAUTH-WG] I-D Action:
draft-ietf-oauth-signed-http-request-00.txt

Hi Justin

I see a fair bit of interest toward this work now being shown from my
colleagues; it would help if the next draft could clarify which HTTP
headers can be signed given it is difficult to get hold of some of HTTP
headers typically created by a low level HTTP transport component.

Thanks, Sergey

On 21/07/14 14:58, internet-dra...@ietf.org wrote:
 >
 > A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 >   This draft is a work item of the Web Authorization Protocol Working
Group of the IETF.
 >
 >  Title   : A Method for Signing an HTTP Requests for
OAuth
 >  Authors : Justin Richer
 >John Bradley
 >Hannes Tschofenig
 > Filename: draft-ietf-oauth-signed-http-request-00.txt
 > Pages   : 11
 > Date: 2014-07-21
 >
 > Abstract:
 > This document a method for offering data origin authentication and
 > integrity protection of HTTP requests.  To convey the relevant data
 > items in the request a JSON-based encapsulation is used and the JSON
 > Web Signature (JWS) technique is re-used.  JWS offers integrity
 > protection using symmetric as well as asymmetric cryptography.
 >
 >
 > The IETF datatracker status page for this draft is:
 > https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/
 >
 > There's also a htmlized version available at:
 > http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00
 >
 >
 > Please note that it may take a couple of minutes from the time of
submission
 > until the htmlized version and diff are available at tools.ietf.org.
 >
 > Internet-Drafts are also available by anonymous FTP at:
 > ftp://ftp.ietf.org/internet-drafts/
 >
 > ___
 > OAuth mailing list
 > OAuth@ietf.org
 > https://www.ietf.org/mailman/listinfo/oauth
 >

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00.txt

[Sergey Beryozkin]

Hi Justin

I see a fair bit of interest toward this work now being shown from my 
colleagues; it would help if the next draft could clarify which HTTP 
headers can be signed given it is difficult to get hold of some of HTTP 
headers typically created by a low level HTTP transport component.


Thanks, Sergey

On 21/07/14 14:58, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

 Title   : A Method for Signing an HTTP Requests for OAuth
 Authors : Justin Richer
   John Bradley
   Hannes Tschofenig
Filename: draft-ietf-oauth-signed-http-request-00.txt
Pages   : 11
Date: 2014-07-21

Abstract:
This document a method for offering data origin authentication and
integrity protection of HTTP requests.  To convey the relevant data
items in the request a JSON-based encapsulation is used and the JSON
Web Signature (JWS) technique is re-used.  JWS offers integrity
protection using symmetric as well as asymmetric cryptography.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-03.txt

[Sergey Beryozkin]

Hi Justin

returning a client public/confidential status may be useful in case RS 
chooses to allow for a more restricted access to public clients in cases 
where both public & private clients are accepted


Thanks, Sergey
On 09/12/14 15:59, Sergey Beryozkin wrote:

Hi Justin

IMHO the section 2.1 [1] requires more work.

First, "resource_id". Having such a parameter does not add anything to
the interoperability side of the spec. It is a "server specific
string..." which may be anything and as such a 3rd party AS is unlikely
to do any work around this parameter unless both RS and AS are from the
same provider.
IMHO it either has to be dropped, the text "The endpoint MAY allow other
parameters to provide further context to the query" covers whatever else
that server may want to add or attach some more specific meaning to it.
Besides that, the MUST authentication requirement covers properly a
possible RS identification requirement.
I'd rather have a "resource_id" representing an RS base address or
better, a current request URI, which in combination with an optional
client_ip can help AS to make a more specific introspection action.

I also suggested to promote a parameter like "client_ip". Just referring
to a possibility of RS reporting a client IP adress does not help
improving the interoperability either with respect to RS and AS offered
by different providers working with a client IP property

Thanks, Sergey



[1]
http://tools.ietf.org/html/draft-ietf-oauth-introspection-03#section-2.1



On 07/12/14 03:38, Justin Richer wrote:

… and I just noticed hanging text at the top of section 2.2 due to the
JWT claims edit. My working copy has removed the extraneous text
“Several of these”.

Also, as always, latest XML is up on GitHub:

https://github.com/jricher/oauth-spec

— Justin
On Dec 6, 2014, at 10:34 PM, Justin Richer  wrote:


Small update to introspection, now the returned values reference the
JWT claims specifically (as requested). Also updated the HTTP and
HTML references.

No normative changes.

— Justin

On Dec 6, 2014, at 10:32 PM, internet-dra...@ietf.org wrote:



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Web Authorization Protocol Working
Group of the IETF.

   Title   : OAuth 2.0 Token Introspection
   Author  : Justin Richer
Filename: draft-ietf-oauth-introspection-03.txt
Pages   : 12
Date: 2014-12-06

Abstract:
  This specification defines a method for a protected resource to query
  an OAuth 2.0 authorization server to determine the active state of an
  OAuth 2.0 token and to determine meta-information about this token.
  OAuth 2.0 deployments can use this method to convey information about
  the authorization context of the token from the authorization server
  to the protected resource.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-introspection-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-03


Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-03.txt

[Sergey Beryozkin]

Hi Justin

IMHO the section 2.1 [1] requires more work.

First, "resource_id". Having such a parameter does not add anything to 
the interoperability side of the spec. It is a "server specific 
string..." which may be anything and as such a 3rd party AS is unlikely 
to do any work around this parameter unless both RS and AS are from the 
same provider.
IMHO it either has to be dropped, the text "The endpoint MAY allow other 
parameters to provide further context to the query" covers whatever else 
that server may want to add or attach some more specific meaning to it. 
Besides that, the MUST authentication requirement covers properly a 
possible RS identification requirement.
I'd rather have a "resource_id" representing an RS base address or 
better, a current request URI, which in combination with an optional 
client_ip can help AS to make a more specific introspection action.


I also suggested to promote a parameter like "client_ip". Just referring 
to a possibility of RS reporting a client IP adress does not help 
improving the interoperability either with respect to RS and AS offered 
by different providers working with a client IP property


Thanks, Sergey



[1] http://tools.ietf.org/html/draft-ietf-oauth-introspection-03#section-2.1



On 07/12/14 03:38, Justin Richer wrote:

… and I just noticed hanging text at the top of section 2.2 due to the JWT 
claims edit. My working copy has removed the extraneous text “Several of these”.

Also, as always, latest XML is up on GitHub:

https://github.com/jricher/oauth-spec

— Justin
On Dec 6, 2014, at 10:34 PM, Justin Richer  wrote:


Small update to introspection, now the returned values reference the JWT claims 
specifically (as requested). Also updated the HTTP and HTML references.

No normative changes.

— Justin

On Dec 6, 2014, at 10:32 PM, internet-dra...@ietf.org wrote:



A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

   Title   : OAuth 2.0 Token Introspection
   Author  : Justin Richer
Filename: draft-ietf-oauth-introspection-03.txt
Pages   : 12
Date: 2014-12-06

Abstract:
  This specification defines a method for a protected resource to query
  an OAuth 2.0 authorization server to determine the active state of an
  OAuth 2.0 token and to determine meta-information about this token.
  OAuth 2.0 deployments can use this method to convey information about
  the authorization context of the token from the authorization server
  to the protected resource.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-introspection-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

[Sergey Beryozkin]

Hi Justin,
On 02/12/14 15:36, Richer, Justin P. wrote:

However, I think it's very clear how PoP tokens would work. You send the
value returned as the "access_token" in the token endpoint response,
which is effectively the public portion of the PoP token. Just like a
bearer token, this value is passed as-is from the client to the RS and
would be passed as-is from the RS to the AS during introspection. The AS
can then use that to look up the key and return it in an
as-yet-unspecified field so that the RS can validate the request. The RS
wouldn't send the signature or signed portion of the request for the AS
to validate -- that's a bad idea. But these are all details that we can
work out in the PoP-flavored extension.

For me, as a non-security expert but as an implementer, the idea of spreading 
the token validation across multiple nodes (AS + RS), and with getting AS 
sending the secret key to RS, does not appear to be very sound either, it might 
be the right idea but the one which would likely more difficult to do right - 
with AS having to orchestrate a secure key delivery to RS while partially 
validating the token too.

And there will be yet another specification/extension.

I suggested it might limit the interoperability reach of this draft and of the 
pop token idea - I'm sorry - most likely I'm wrong but...

The signature, the RS request URI, these are all the public parameters that AS 
can act upon. Sending the key to RS should be supported by capable OAuth2 RS 
implementations but IMHO the RS delegating the signature validation to AS also 
works...

Just my 2c


Secure key delivery is pretty straight forward -- you can just pass the key in 
a JWK over TLS in response to an authorized request. For asymmetric keys, this 
would even just be the public key used to validate the signature, so there's 
not really any security leakage. Symmetric keys are trickier, but that's a well 
known tradeoff.

I think that in practice you'd lose too much of the context of the request to the RS in order to 
make a meaningful decision at the AS. I would rather token introspection be limited to "what 
can you tell me about this token" and not the larger, stickier question of "what should I 
do with this request". But I think that you're right in that if we solve the former, we have a 
stepping stone for solving the latter. I don't, however, want us to get caught up in an 
ocean-boiling exercise when we've got one solidly useful puddle we can do something about.


Your language is very rich :-)


As such, I punted all mention of PoP to the appendix and I personally think it 
should stay there as a note of some kind, saying that it's out of scope but not 
out of reach.


+1, it is a good compromise.

Thanks for the clarifications,
Sergey

  -- Justin




On Dec 2, 2014, at 10:07 AM, Sergey Beryozkin  wrote:


Hi Justin

Please see a comment below

On 02/12/14 14:05, Justin Richer wrote:

Hannes, thanks for the review. Comments inline.

On 12/2/2014 6:23 AM, Hannes Tschofenig wrote:

Hi Justin,

I have a few remarks regarding version -01 of the token introspection
document.

* Terminology

The token introspection protocol is a client-server protocol but the
term "client" already has a meaning in OAuth. Here the client of the
token introspection protocol is actually the resource server. I believe
it would make sense to clarify this issue in the terminology section or
in the introduction. Maybe add a figure (which you could copy from
Figure 4 of
http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt.

Maybe you want to call these two parties, the introspection client and
the introspection server.


I tried to avoid the word "client" for this very reason. The draft used
to say "client or protected resource" throughout, but in a few years of
deployment experience it's become clear that it's pretty much just
protected resources that need to do introspection so I changed that text
throughout. I don't think that "introspection client" will help here
because the party already has a name from OAuth and we should inherit it.


* Scope

I think the document needs to be very clear that is only applicable to
bearer tokens (and not to PoP tokens). This issue was raised at the last
IETF meeting as well.


I think the document should be clear that it *specifies* the mechanism
for bearer tokens, since that's the only OAuth token type that's defined
publicly right now, and that the details for PoP will have to be
specified in another spec -- that's exactly what Appendix C is there
for, and if that can be clearer, please suggest better text.

However, I think it's very clear how PoP tokens would work. You send the
value returned as the "access_token" in the token endpoint response,
which is effectively the public portion of the PoP token. Just like a
beare

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

[Sergey Beryozkin]

Hi Justin

Please see a comment below

On 02/12/14 14:05, Justin Richer wrote:

Hannes, thanks for the review. Comments inline.

On 12/2/2014 6:23 AM, Hannes Tschofenig wrote:

Hi Justin,

I have a few remarks regarding version -01 of the token introspection
document.

* Terminology

The token introspection protocol is a client-server protocol but the
term "client" already has a meaning in OAuth. Here the client of the
token introspection protocol is actually the resource server. I believe
it would make sense to clarify this issue in the terminology section or
in the introduction. Maybe add a figure (which you could copy from
Figure 4 of
http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt.

Maybe you want to call these two parties, the introspection client and
the introspection server.


I tried to avoid the word "client" for this very reason. The draft used
to say "client or protected resource" throughout, but in a few years of
deployment experience it's become clear that it's pretty much just
protected resources that need to do introspection so I changed that text
throughout. I don't think that "introspection client" will help here
because the party already has a name from OAuth and we should inherit it.


* Scope

I think the document needs to be very clear that is only applicable to
bearer tokens (and not to PoP tokens). This issue was raised at the last
IETF meeting as well.


I think the document should be clear that it *specifies* the mechanism
for bearer tokens, since that's the only OAuth token type that's defined
publicly right now, and that the details for PoP will have to be
specified in another spec -- that's exactly what Appendix C is there
for, and if that can be clearer, please suggest better text.

However, I think it's very clear how PoP tokens would work. You send the
value returned as the "access_token" in the token endpoint response,
which is effectively the public portion of the PoP token. Just like a
bearer token, this value is passed as-is from the client to the RS and
would be passed as-is from the RS to the AS during introspection. The AS
can then use that to look up the key and return it in an
as-yet-unspecified field so that the RS can validate the request. The RS
wouldn't send the signature or signed portion of the request for the AS
to validate -- that's a bad idea. But these are all details that we can
work out in the PoP-flavored extension.
For me, as a non-security expert but as an implementer, the idea of 
spreading the token validation across multiple nodes (AS + RS), and with 
getting AS sending the secret key to RS, does not appear to be very 
sound either, it might be the right idea but the one which would likely 
more difficult to do right - with AS having to orchestrate a secure key 
delivery to RS while partially validating the token too.


And there will be yet another specification/extension.

I suggested it might limit the interoperability reach of this draft and 
of the pop token idea - I'm sorry - most likely I'm wrong but...


The signature, the RS request URI, these are all the public parameters 
that AS can act upon. Sending the key to RS should be supported by 
capable OAuth2 RS implementations but IMHO the RS delegating the 
signature validation to AS also works...


Just my 2c

Sergey



As I noted in the other thread,
we'll have to make a similar extension for Revocation, so I still don't
think it makes sense to hold up this work and wait for PoP to be
finished because it's useful now, as-is.



* Meta-Information

You have replicated a lot of the claims defined in
https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31
and I am wondering why you have decided to not just re-use the entire
registry from JWT?

If you want to create a separate registry (which I wouldn't recommend)
then you have to put text into the IANA consideration section.


The idea was to inherit JWT's syntax and semantics, at least on the
wire, and add additional fields. It probably makes sense to just inherit
the JWT registry, so we can do that.


When you write:

"
The endpoint MAY allow other parameters to provide further context to
the query.
"

You could instead write that the token introspection MUST ignore any
parameters from the request message it does not understand.


Noted, will add.


Of course, there is the question whether any of those would be security
critical and hence ignoring them would cause problems?!


Anything security critical would be provider-specific, in which case it
wouldn't ignore them.


* Security

The requirement for authenticating the party issuing the introspection
request to the token introspection endpoint is justified in the security
and the privacy consideration section. The security threat is that an
attacker could use the endpoint to testing for tokens. The privacy
threat is that a resource server learns about the content of the token,
which may contain personal data. I see the former as more dangerous than
the latter since 

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

[Sergey Beryozkin]

Hi Hannes

Thanks for the clarifications, comments below...
On 02/12/14 12:02, Hannes Tschofenig wrote:

Hi Sergey,

On 12/02/2014 12:30 PM, Sergey Beryozkin wrote:


* Scope

I think the document needs to be very clear that is only applicable to
bearer tokens (and not to PoP tokens). This issue was raised at the last
IETF meeting as well.


Interesting, I was reading the doc yesterday and thought it was good it
was not talking about specific access token types :-)

I wonder why a pop token can not be introspected in the interoperable
way as per the text for the resource server to tale the authorization
decision ?



The problem is that the AS needs to have the same context as the RS. In
the bearer token case, the RS really only needs to pass the the access
token along but in the PoP case one could imagine a couple of different
solutions.

A possible solution is that the AS sends the RS the necessary key so
that the RS is able to verify the MAC or digital signature covering the
request.

The story would again be different if the PoP solution involves TLS.

Yet another solution would be to also forward the entire request to the
AS (which I wouldn't do).

This is not specified in the current version of token introspection and,
from the responses Justin gave at the last IETF meeting, he does not
want to wait till the PoP work is finished to actually work out the
details.

Finally, from a security point of view it would be extremely important
that the AS only provides a key to the RS if the RS is (a) authenticated
and (b) the audience field from the token matches the RS since otherwise
the PoP security degrades to a bearer token.


I see the draft specifying an optional resource_id hint (which I read 
being an actual request URI) which is the primary signing material in 
the pop case, the extra parameters like the nonce/timestamp can be 
forwarded along.


I agree it does not make sense to forward the actual body but that is 
probably going to be a very rare case where a body hash is also provided.


Explicitly disallowing the support for the pop tokens in the 
introspection text might the interoperability reach of either pop tokens 
or token introspections in cases where a given RS integrates with a 3rd 
party AS. May be it is a Security Considerations draft issue which would 
make it more open for pop tokens


Thanks, Sergey



Ciao
Hannes


Thanks, Sergey





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

[Sergey Beryozkin]

Hi Hannes
On 02/12/14 11:23, Hannes Tschofenig wrote:

Hi Justin,

I have a few remarks regarding version -01 of the token introspection
document.

* Terminology

The token introspection protocol is a client-server protocol but the
term "client" already has a meaning in OAuth. Here the client of the
token introspection protocol is actually the resource server. I believe
it would make sense to clarify this issue in the terminology section or
in the introduction. Maybe add a figure (which you could copy from
Figure 4 of
http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt.

Maybe you want to call these two parties, the introspection client and
the introspection server.

* Scope

I think the document needs to be very clear that is only applicable to
bearer tokens (and not to PoP tokens). This issue was raised at the last
IETF meeting as well.

Interesting, I was reading the doc yesterday and thought it was good it 
was not talking about specific access token types :-)


I wonder why a pop token can not be introspected in the interoperable 
way as per the text for the resource server to tale the authorization 
decision ?


Thanks, Sergey


* Meta-Information

You have replicated a lot of the claims defined in
https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31
and I am wondering why you have decided to not just re-use the entire
registry from JWT?

If you want to create a separate registry (which I wouldn't recommend)
then you have to put text into the IANA consideration section.

When you write:

"
The endpoint MAY allow other parameters to provide further context to
the query.
"

You could instead write that the token introspection MUST ignore any
parameters from the request message it does not understand.

Of course, there is the question whether any of those would be security
critical and hence ignoring them would cause problems?!

* Security

The requirement for authenticating the party issuing the introspection
request to the token introspection endpoint is justified in the security
and the privacy consideration section. The security threat is that an
attacker could use the endpoint to testing for tokens. The privacy
threat is that a resource server learns about the content of the token,
which may contain personal data. I see the former as more dangerous than
the latter since a legitimate resource server is supposed to learn about
the authorization information in the token. An attacker who had gotten
hold of tokens will not only learn about the content of the token but he
will also be able to use it to get access to the protected resource itself.

In any case, to me this sounds like mutual authentication should be
mandatory to implement. This is currently not the case. On top of that
there is single technique mandatory-to-implement outlined either (in
case someone wants to use it). That's in general not very helpful from
an interoperability point of view. Yet another thing to agree on between
the AS and the RS.

* SHOULDs

This is my usual comment that any SHOULD statement should give the
reader enough information about the trade-off decision he has to make.
When should he implement something and when should he skip it?

* Minor items

You write:

"
These include using
structured token formats such as JWT [JWT] or SAML [[ Editor's Note:
Which SAML document should we reference here? ]] and proprietary
inter-service communication mechanisms (such as shared databases and
protected enterprise service buses) that convey token information.
"

Just reference the JWT since that's what we standardize.

* 'Active' claim

you write:
"
active  REQUIRED.  Boolean indicator of whether or not the presented
   token is currently active.  The authorization server determines
   whether and when a given token is in an active state.
"

Wouldn't it make more sense to return an error rather than saying that
this token is not active.

* Capitalization

Reading through the text I see bearer token/Bearer Token, Client/client,
etc. issue.

* AS <-> RS relationship

You write:
"
Since
OAuth 2.0 [RFC6749] defines no direct relationship between the
authorization server and the protected resource, only that they must
have an agreement on the tokens themselves, there have been many
different approaches to bridging this gap.
"

I am not sure what you mean by "defines no relationship" between the AS
and the RS. Of course, there is a relationship. The AS issues tokens for
access for a specific RS. The RS needs to understand the tokens or if it
does not understand them it needs to know which AS to interact with to
learn about the content.

In a nutshell, I am not sure what you want to say with this paragraph
particularly since you state that they have to have an agreement about
the tokens.


Ciao
Hannes



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Access token response in application/jwt format

[Sergey Beryozkin]

Hi

OIDC UserInfo endpoint supports returning UserInfo directly in JSON or 
JWS and/or JWE encoded. It is not only useful for OIDC RP clients but 
also allows for supporting a proper HTTP content negotiation, example, 
the implementation of OIDC UserInfo endpoint has a better choice of 
where an optional JWE/JWS encoding can be done, directly in the code or 
via the filters reacting to HTTP Accept.


IMHO it would be good to get it supported directly in OAuth2 token 
responses too. Among other thing it would also help with making the 
whole JOSE effort more popular.


Just an idea, I do not expect any action from the group, but hopefully 
it will be reviewed over time

Sergey

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-01.txt

[Sergey Beryozkin]

On 01/12/14 10:56, Sergey Beryozkin wrote:

Hi Justin

Nicely written text, as usual.
Few comments:
- I haven't found a reference to a data format of POST requests.
I'm presuming it is going to be a form payload (would mean the server
code can write more or less the same code dealing with POST & GET
queries) ?

Oops :-), sorry, did not scroll down to the example in the text

Thanks, Sergey

- consider directly specifying an optional 'client_ip' property
- consider adding an optional request_method (or request_verb) hint, a
given scope can be restricted to say GET only, can be useful when a
protected resource is written to support GET and POST over the same
resource_id URI;

The text that the endpoint may support other parameters (such a client
ip address) covers the last 2 parameters, but I guess it would be more
inter-operable to 'promote' the parameters that may be of general use.

Thanks, Sergey




On 01/12/14 02:41, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
  This draft is a work item of the Web Authorization Protocol Working
Group of the IETF.

 Title   : OAuth 2.0 Token Introspection
 Author  : Justin Richer
Filename: draft-ietf-oauth-introspection-01.txt
Pages   : 10
Date: 2014-11-30

Abstract:
This specification defines a method for a protected resource to query
an OAuth 2.0 authorization server to determine the active state of an
OAuth 2.0 token and to determine meta-information about this token.
OAuth 2.0 deployments can use this method to convey information about
the authorization context of the token from the authorization server
to the protected resource.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-introspection-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-01


Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-01.txt

[Sergey Beryozkin]

Hi Justin

Nicely written text, as usual.
Few comments:
- I haven't found a reference to a data format of POST requests.
I'm presuming it is going to be a form payload (would mean the server 
code can write more or less the same code dealing with POST & GET queries) ?

- consider directly specifying an optional 'client_ip' property
- consider adding an optional request_method (or request_verb) hint, a 
given scope can be restricted to say GET only, can be useful when a 
protected resource is written to support GET and POST over the same 
resource_id URI;


The text that the endpoint may support other parameters (such a client 
ip address) covers the last 2 parameters, but I guess it would be more 
inter-operable to 'promote' the parameters that may be of general use.


Thanks, Sergey




On 01/12/14 02:41, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

 Title   : OAuth 2.0 Token Introspection
 Author  : Justin Richer
Filename: draft-ietf-oauth-introspection-01.txt
Pages   : 10
Date: 2014-11-30

Abstract:
This specification defines a method for a protected resource to query
an OAuth 2.0 authorization server to determine the active state of an
OAuth 2.0 token and to determine meta-information about this token.
OAuth 2.0 deployments can use this method to convey information about
the authorization context of the token from the authorization server
to the protected resource.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-introspection-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-01.txt

[Sergey Beryozkin]

Hi John
On 27/11/14 19:22, John Bradley wrote:

In sec 6 of openID Connect core we have.

So that the request is a valid OAuth 2.0 Authorization Request, values for the 
response_type and client_id parameters MUST be included using the OAuth 2.0 
request syntax, since they are REQUIRED by OAuth 2.0. The values for these 
parameters MUST match those in the Request Object, if present.

So we should add that in to this text to make it clear that it must still be a 
well formed OAuth 2 request.

Thanks for the clarification, I did assume, while prototyping the 
client_id was available as a dedicated query parameter too

In Connect we do allow for the possibility that a 3rd party might sign a 
request object.

An example was that in some jurisdictions it may be a 3rd party like a privacy 
commissioner that signs the request object so that the IdP know that the RP is 
allowed to request those claims.

The processing by the AS is validate the signature based on the "iss"  
(typically the client) Compare the client_id to the iss and see if the iss is 
authoritative for value of the client_id claim (typically one to one).  Compare the 
client_id claim value with the query parameter client_id value and reject if not the 
same.  (you could do that first if you want)

The idea of the hash is that allows the AS discover if the content of the 
request file has changed without getting it.

The example from connect is:

   
https://client.example.org/request.jwt#GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM

The server needs to remember the full URI of the request object and refetch it 
when the fragment changes.

Without the fragment the AS would need to rely on http:caching and at-least to 
a HEAD each time.

That section can be expanded.

Very nice explanation above, thanks, sorry I did not do my home work and 
reviewed the connect text :-).


Thanks, Sergey


John B.




On Nov 27, 2014, at 2:55 PM, Sergey Beryozkin  wrote:

Hi

Should the text require that a "client_id" parameter is always included as a 
query parameter too ?

If it is only inside a 'request' parameter then how the server would identify a 
client specific key that can be used to validate the signature ?

Or is the idea that if it is JWS and no client_id query parameter is available 
then a client id is extracted first, the key is identified and then the 
signature is validated ?

Also, a simple example how an optional file hash is specified when a 
request_uri is used would be useful

Many thanks, Sergey
On 13/11/14 04:07, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

 Title   : Request by JWS ver.1.0 for OAuth 2.0
 Authors : Nat Sakimura
   John Bradley
Filename: draft-ietf-oauth-jwsreq-01.txt
Pages   : 9
Date: 2014-11-12

Abstract:
The authorization request in OAuth 2.0 utilizes query parameter
serialization.  This specification defines the authorization request
using JWT serialization.  The request is sent through "request"
parameter or by reference through "request_uri" parameter that points
to the JWT, allowing the request to be optionally signed and
encrypted.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-jwsreq-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-01.txt

[Sergey Beryozkin]

Hi

Should the text require that a "client_id" parameter is always included 
as a query parameter too ?


If it is only inside a 'request' parameter then how the server would 
identify a client specific key that can be used to validate the signature ?


Or is the idea that if it is JWS and no client_id query parameter is 
available then a client id is extracted first, the key is identified and 
then the signature is validated ?


Also, a simple example how an optional file hash is specified when a 
request_uri is used would be useful


Many thanks, Sergey
On 13/11/14 04:07, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

 Title   : Request by JWS ver.1.0 for OAuth 2.0
 Authors : Nat Sakimura
   John Bradley
Filename: draft-ietf-oauth-jwsreq-01.txt
Pages   : 9
Date: 2014-11-12

Abstract:
The authorization request in OAuth 2.0 utilizes query parameter
serialization.  This specification defines the authorization request
using JWT serialization.  The request is sent through "request"
parameter or by reference through "request_uri" parameter that points
to the JWT, allowing the request to be optionally signed and
encrypted.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-jwsreq-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-spop-04: a way of making code_challenge

[Sergey Beryozkin]

Hi John

Thanks for going over it again and explaining it all so nicely, even I 
do understand it now (I'd like to think so :-)) why using a client id as 
a salt does not add much to the signature strength.
I thought the idea was consider to introduce some extra randomization, 
where say even multiple clients with the same id can sometimes use a 
server id as opposed to a client id to add to the signature function 
input. May be I've misunderstood.

It's been an interesting thread to watch for sure :-)

Many thanks, Sergey
On 19/11/14 13:17, John Bradley wrote:

Hi Sergey,

If we change from a SHA256 function over the code_verifier to a SHA256 over the 
concatenation of the code_verifier and client_id, that would be defined in the 
spec.
We would not do both, and the salt would not be a real random.   There would be 
many instances of a client all using the same salt value.

The client_id is sent in both the request to the authorization endpoint and the 
token endpoint and is validated by having a registered redirect_uri.

The question is if doing that adds any net security given the likely attacks.

I originally proposed using a SHA256 HMAC of the client)id in one of the first 
drafts.   (effectively the same as a hash of the concatenation of the two 
values)

That was taken out as being too complicated for developers based on feedback.

The compromise was a simple SHA256 hash of the code verifier.   This allowed 
Google and others to support this transform as Mandatory to Implement on the 
server.

I have been convinced that as long as the code_verifier as enough entropy 
(256bits) using the HMAC didn't add enough security to warrant the additional 
concatenation step.

In the theoretical yes splitting the search space by adding a salt is better 
than not if the attacker is using precomputed values, and is a wash if the 
attacker can compute hashes useng the salt in real time as fast or faster than 
using a lookup.

The only downside to using a salt is that people may elect to reduce the size 
of code_verifier because they feel the salt is providing some security.

If the client uses a 128bit random  for code verifier and a fixed 128bit 
client_id to produce a 256bit has that would be significantly less secure than 
using using a 256bit code_verifier if the attacker is using oclhashcat with 
GPU.  http://hashcat.net/oclhashcat/

If we do go back to effectively doing a HMAC then we do need to be careful that 
people don't reduce the entropy of code_verifyer.

John B.


On Nov 19, 2014, at 4:01 AM, Sergey Beryozkin  wrote:

Hi

Apologies for getting into this thread (I do not understand most of the 
mathematics at this stage :)),
On 19/11/14 06:43, takamichi saito wrote:

(2014/11/18 13:54), Bill Mills wrote:

There will be no rainbow table for 256bits of search space.  Suppose
then that clientID has 256 possible values.  How does salting with
client ID do anything more than making the search space 264 bits?

You keep saying that a salt is better than just adding entropy, but
never actually justifying it.




Adding client_ID is not only for like adding password's salt.
Adding client_ID is not same as adding password's salt in this context.


You've mentioned it would separate a search space, but as far as I understand 
that would require a client to randomly add either its client_id or server_id 
to the signature function. If it is only adding a client id then it sounds like 
a salt. Is that right ? I think I can understand that.
The question is, where is a 'server_id' coming from and how a server would know 
that the signature was calculated with a client_id or server_id added in ?

Sorry if it is all just the noise...

Thanks, Sergey




On Monday, November 17, 2014 8:34 PM, takamichi saito
 wrote:
(2014/11/18 13:17), Bill Mills wrote:

Again, the only value of including client ID or any other value in
this case is to increase the number of bits of entropy in the value
being hashed. Using client ID is only useful if it's actually got
decent entropy in it, if it's just a version number then or a server
name or address it adds very little.



Client_ID is not for adding entropy.
Again, Client_ID is separating the attacker's searching space.


Yes, salting is valuable for passwords which have very low entropy.
But as has been discussed it adds little in this case.  Your
arguments are correct for passwords but not for 256 bits of random
number.



I agree that human-made password is low entropy.
As I say, adding Client_ID can force the attacker has to search the
value in each attack.
If the attacker uses GPU, he can not get the value within the session.

I never confuse about password in these discussions.




Regards,

-bill



On Monday, November 17, 2014 7:27 PM, takamichi saito
 wrote:

I agree that GPU can/may find the value on the fly.
But, it can not find it within the session.
The draft idea is enough against the attack with GPU.