Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

[Bill Burke]

This is an honest question: How important is the actor stuff to the
players involved?  Are people going to use it?  IMO, its an edge case
and I think more important areas, like external token exchange (realm
to realm, domain to domain) are being neglected.  I'm quite unfamiliar
how consensus is reached in this WG or the IETF, so I hope I'm not
sounding rude.  Just trying to provide some constructive feedback.



On Thu, May 17, 2018 at 9:26 AM, Mike Jones  wrote:
> Moving the actor claim to a separate specification would only make things 
> more complicated for developers.  There already plenty of OAuth specs.  
> Needlessly adding another one will only make related things harder to find.
>
> Just like in the JWT [RFC 7519] spec itself in which use of all the claims is 
> optional, use of the actor claim in this spec.  If you don't need it, don't 
> use it.  Just because some won't use it is no better an argument for moving 
> it to a different spec than the argument that JWT should have defined each of 
> its claims in different specs.  That would have made things harder, not 
> easier.
>
> -- Mike
>
> -Original Message-
> From: OAuth  On Behalf Of Bill Burke
> Sent: Thursday, May 17, 2018 2:11 PM
> To: Brian Campbell 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
>
> My personal opinion is that I'm glad this actor stuff is optional.
> For one, none of our users have asked for it and really only do simple 
> exchanges.  Secondly, the rules for who can exchange what for what is 
> controlled and defined within our AS.  Makes things a lot simpler on the 
> client.  I kind of wish the actor stuff would be defined in a separate 
> specification.  I don't see us implementing it unless users start asking us 
> to.
>
> On Wed, May 16, 2018 at 6:11 PM, Brian Campbell  
> wrote:
>> Well, it's already called the "actor claim" so the claimed part is
>> kind of implied. And "claimed actor claim" is a rather awkward.
>> Really, all JWT claims are "claimed something" but they don't include
>> the "claimed" bit in the name. RFC 7519, for example, defines the
>> subject claim but not the claimed subject claim.
>>
>> On Fri, Apr 20, 2018 at 11:38 AM, Denis  wrote:
>>>
>>> Brian,
>>>
>>> Eric said: "what is the RP supposed to do when they encounter it?
>>> This seems kind of under specified".
>>>
>>> After reading your explanations below, it looks like the RP can do
>>> anything he wants with the "actor".
>>> It is a "claimed actor" and, if we keep the concept, it should be
>>> called as such. Such a claim cannot be verified.
>>> A RP could copy and paste that claim in an audit log. No standard
>>> action related to the content of such a claim can be specified in the
>>> spec. If the content of a "claimed actor" is used by the RP, it
>>> should be only used as an hint and thus be subject to other
>>> verifications which are not specified in this specification.
>>>
>>> Denis
>>>
>>> Eric, I realize you weren't particularly impressed by my prior
>>> statements about the actor claim but, for lack of knowing what else
>>> to say, I'm going to kind of repeat what I said about it over in the
>>> Phabricator tool and add a little color.
>>>
>>> The actor claim is intended as a way to express that delegation has
>>> happened and identify the entities involved. Access control or other
>>> decisions based on it are at the discretion of the consumer of the
>>> token based on whatever policy might be in place.
>>>
>>> There are JWT claims that have concise processing rules with respect
>>> to whether or not the JWT can be accepted as valid. Some examples are "aud"
>>> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RFC 7519.
>>> E.g. if the token is expired or was intended for someone or something
>>> else, reject it.
>>>
>>> And there are JWT claims that appropriately don't specify such
>>> processing rules and are solely statements of fact or circumstance.
>>> Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At) claims are 
>>> good examples of such.
>>> There might be application or policy specific rules applied to the
>>> content of those kinds of claims (e.g. only subjects from a
>>> particular organization are able to access tenant specific

Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

[Bill Burke]

the token and
>> prior systems being nested.. What actually gets done with that information
>> is up to the respective systems involved. There might be policy about what
>> system is allowed to call what other system that is enforced. Or maybe the
>> info is just written to an audit log somewhere. Or something else. I don't
>> know. But whatever it is application/deployment/policy dependent and not
>> specifiable by a spec.
>>
>>
>>
>>
>>
>>
>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla  wrote:
>>>
>>> Hi folks,
>>>
>>> I've gone over draft-ietf-oauth-token-exchange-12 and things seem
>>> generally OK. I do still have one remaining concern, which is about
>>> the actor claim. Specifically, what is the RP supposed to do when they
>>> encounter it? This seems kind of underspecified.
>>>
>>> In particular:
>>>
>>> 1. What facts am I supposed to know here? Merely that everyone in
>>>the chain signed off on the next person in the chain acting as them?
>>>
>>> 2. Am I just supposed to pretend that the person presenting the token
>>>is the identity at the top of the chain? Say I have the
>>>delegation A -> B -> C, and there is some resource which
>>>B can access but A and C cannot, should I give access?
>>>
>>> I think the first question definitely needs an answer. The second
>>> question I guess we could make not answer, but it's pretty hard
>>> to know how to make a system with this left open..
>>>
>>> -Ekr
>>>
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
>> material for the sole use of the intended recipient(s). Any review, use,
>> distribution or disclosure by others is strictly prohibited..  If you have
>> received this communication in error, please notify the sender immediately
>> by e-mail and delete the message and any file attachments from your
>> computer. Thank you.
>>
>> ___
>> 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
>>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
> material for the sole use of the intended recipient(s). Any review, use,
> distribution or disclosure by others is strictly prohibited..  If you have
> received this communication in error, please notify the sender immediately
> by e-mail and delete the message and any file attachments from your
> computer. Thank you.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



-- 
Bill Burke
Red Hat

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

[OAUTH-WG] public clients and token exchange

[Bill Burke]

We have a need for public clients to perform token exchanges.  Anybody
have any recommended policies for this?  I'm worried about untrusted
services obtaining a bearer token that they can exchange for upgraded
permissions.  The Auth Server has to put a lot of trust in the public
client to do the right thing.

What should be the initial access token the public client gets?

1) One approach is that it receives an access token devoid of
privileges.  This forces the public client to request an exchange
before invoking on anything.  Then what should be the validation
policy with teh Auth Server?  Do not allow upgrading of token unless
the token being exchanged has zero scopes/audiences?

2) Another approach is that the initial access token has all privilges
the public client needs and the public client downgrades the token
before performing invocations.  The auth server only needs to check
that the client is asking for a downgrade.

3) The last approach we are considering is a combination of #1 and to
only allow public clients to exchange a refresh token.  Being in
possession of a refresh token means that the public client has been
involved with a code to token flow, or a password credentials grant.
For code to token, this means the public client had a valid redirect
uri.  For password credentials grant, the client was trusted enough to
obtain user credentials.






-- 
Bill Burke
Red Hat

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

Re: [OAUTH-WG] What Does Logout Mean?

[Bill Burke]

On Fri, Mar 30, 2018 at 2:47 PM, Richard Backman, Annabelle
 wrote:
> It sounds like you're asking the OP to provide client-side session management 
> as a service. There may be value in standardizing that, but I think it goes 
> beyond what Backchannel Logout is intended to do.

Sure, sort of.  Though, we would have never implemented these
extensions if back channel logout didn't exist as a concept and
requirement.  Its all in the sometimes ugly business of supporting
application developers who have a variety of deployment requirements
and restrictions.

Bill

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

Re: [OAUTH-WG] What Does Logout Mean?

[Bill Burke]

On Fri, Mar 30, 2018 at 12:57 PM, Richard Backman, Annabelle
 wrote:
>
> FWIW, our OP implementation allows RPs to register their node specific
> logout endpoints at boot.  This request is authenticated via client
> authentication.  We also extended code to token request to transmit the
> local session id.  The OP stores this information.  Backchannel logout POSTS
> to each and every registered node and transmits a JWS signed by the OP
> containing the local session ids to invalidate.  That's been enough to cover
> all the weirdness out there so far.
>
> [richanna]
>
> What does “at boot” mean in the context of OpenID Connect? Do you mean that
> for every logout, the OP makes a Backchannel Logout request to each of the
> client’s node-specific logout endpoints?

Just in caseThis is all for backchannel logouts which are out of
band from the browser.

Node boots up and registers with the Auth Server its logout endpoint.

POST /authserver/node_registration

client_id=myclient&
client_secret=geheim&
node=https://node.internal:8443/app/oidc/_logout

 As I mentioned earlier, the node doing code to token request will
also pass its local session id so it can be associated with the Auth
server's SID.  When an admin initiates a forced logout, a backchannel
logout request is sent to each client's logout endpoint.  If the
client has nodes that have registered, this request is duplicated to
each node.





> If that’s the case, why can’t the
> client make those calls themselves, from whichever host happens to receive
> the Backchannel Logout request?
>

Your assuming that each node has knowledge of cluster topology which
isn't neccesarily true.  Each additional proprietary extension we've
made is optional.  Nodes can optionally register themselves.  Nodes
can optionally send local session ids with the code to token request.


>
>
> Since the client only cares about node-local state, they should be able to
> maintain the mapping between OP session IDs and local session IDs on their
> side.
>

Considering a cluster of load balanced web applications that dont'
have session replication and don't have knowledge of cluster topology.
The only way for the Auth Server to perform backchannel logout is to
send the same backchannel logout to each and every node.

There's also the case where the nodes do support session replication,
but don't have a way to get at topology or a way to store the
association between the SID and application session id.  In this case
you don't need node registration, but you do need a way to associate
the SID with the local session id.

As a IDP vendor, you have to support all these types of clients.
Telling developers that they are just going to have to manage this
themselves is not really an option if you want adoption.

Bill

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

Re: [OAUTH-WG] What Does Logout Mean?

[Bill Burke]

On Wed, Mar 28, 2018 at 4:09 PM, Richard Backman, Annabelle <
richa...@amazon.com> wrote:

> That makes somewhat more sense to me if we’re talking about applications
> with sticky sessions. Adding a session-specific logout URI introduces
> security concerns (e.g. how does the OP validate the URI) and only works if
> the RP can provide URIs that target individual hosts in their fleet. The
> “is this SID valid?” endpoint solution that David described doesn’t scale
> and depends on SID (which is OPTIONAL). Both shift the burden of state
> management onto the OP, which may not be in any better position to handle
> it.
>
>
>

FWIW, our OP implementation allows RPs to register their node specific
logout endpoints at boot.  This request is authenticated via client
authentication.  We also extended code to token request to transmit the
local session id.  The OP stores this information.  Backchannel logout
POSTS to each and every registered node and transmits a JWS signed by the
OP containing the local session ids to invalidate.  That's been enough to
cover all the weirdness out there so far.


> This seems like something that needs to be addressed in the client
> implementations rather than in the specification. Especially when we
> consider that there are implementation-specific questions lurking in the
> edge cases. (e.g. what happens when a user comes in with valid cookies, but
> no server-side session state?)
>
>
>

Then,isn't any backchannel logout specification more of a framework than an
actual protocol?


-- 
Bill Burke
Red Hat
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] What Does Logout Mean?

[Bill Burke]

On Wed, Mar 28, 2018 at 1:40 PM, Richard Backman, Annabelle <
richa...@amazon.com> wrote:

> I'm reminded of this session from IIW 21
> . ☺
> I look forward to reading the document distilling the various competing use
> cases and requirements into some semblance of sanity.
>
>
>
> > If the framework has no way of invalidating a session across the cluster…
>
>
>
> Is this a common deficiency in application frameworks? It seems to me that
> much of the value of a server-side session record is lost if its state
> isn’t synchronized across the fleet.
>
>
>
"modern" apps are REST based with Javascript frontends, but there's still a
ton of "old school" developers out there.

Was involved with developing an application server for over a decade
(JBoss)...There were many app developers that didn't want to store app
session information in a database (as David says) or deal with the
headaches of session replication so they just set up their load balancer to
do session affinity (sticky sessions).  That way the login session was
always local.  If the oidc logout spec allowed the client to register
logout callback tied to the token's session (like maybe during code to
token), that might be a simple way to solve many of these issues too.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] What Does Logout Mean?

[Bill Burke]

The biggest problem for us [1] is backchannel logout and we had to add
a lot of proprietary protocols on top of OIDC's backchannel logout
protocol.  Specifically for "traditional" non-Javascript applications
that have multiple endpoints behind a load balancer.   You are really
at the mercy of the application frameworks and infrastructure used to
secure and cluster the application.   If the framework has no way of
invalidating a session across the cluster, then you're forced to
register each endpoint and have the OP make a logout request to each
of those endpoints.  Even if the framework has a way to invalidate a
session across a cluster, the the Session ID is owned and asserted by
the OP.  This means that the application framework has to have a way
to associate the OP's Session ID with a local session.  If there's no
way to do this cross cluster, then you're often forced to fallback to
registering each endpoint and the OP making individual backchannel
logout requests to each RP endpoint.

>From a product point of view, the only viable solution is to front
apps with a security proxy.  Otherwise you're resolving the problem
for each and every application framework you'd provide an
adapter/library for.

[1] https://keycloak.org

On Wed, Mar 28, 2018 at 9:53 AM, Mike Jones  wrote:
> Digital identity systems almost universally support end-users logging into
> applications and many also support logging out of them.  But while login is
> reasonable well understood, there are many different kinds of semantics for
> “logout” in different use cases and a wide variety of mechanisms for
> effecting logouts.
>
>
>
> I led a discussion on the topic “What Does Logout Mean?” at the 2018 OAuth
> Security Workshop in Trento, Italy, which was held the week before IETF 101,
> to explore this topic.  The session was intentionally a highly interactive
> conversation, gathering information from the experts at the workshop to
> expand our collective understanding of the topic.  Brock Allen – a
> practicing application security architect (and MVP for ASP.NET/IIS) –
> significantly contributed to the materials used to seed the discussion.  And
> Nat Sakimura took detailed notes to record what we learned during the
> discussion.
>
>
>
> Feedback on the discussion was uniformly positive.  It seemed that all the
> participants learned things about logout use cases, mechanisms, and
> limitations that they previously hadn’t previously considered.
>
>
>
> Materials related to the session are:
>
> Presentation used to bootstrap the discussions (pptx) (pdf)
> Notes from the session
> Workshop submission (pdf)
> OpenID Connect issue “Create a document explaining "single logout"
> semantics”
>
>
>
>-- Mike
>
>
>
> P.S. This note was also posted at http://self-issued.info/?p=1804 and as
> @selfissued.
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



-- 
Bill Burke
Red Hat

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

Re: [OAUTH-WG] [token-exchange] Parameters to support external token exchange

[Bill Burke]

How the target STS processes the external token is up to the STS.  The
external token could solely be used as an authentication mechanism.
The client must be registered and known by the STS, so it can decide
if the client is allowed to exchange an external token, and what
target audience or resource the client is allowed to ask for.  At
least this is how it works in our implementation.  With Facebook
token, the STS knows that it is a Facebook token and was obtained to
access Facebook APIs.  I don't see the vulnerabilites right now as
much different than an internal exchange or bearer token invocations.
 Clients need to be aware that they should downgrade tokens before
passing them to less trusted target endpoints.

On Mon, Dec 11, 2017 at 6:23 PM, Brian Campbell
 wrote:
> The words implicit vs. explicit might not have been the best choice but the
> concepts are complicated and subtle and I was (and still am) at a bit of a
> lose for the right language to describe things.
>
> By explicit what I was trying to express is that the token that is going
> cross-domain is explicitly intended for that purpose and includes things
> like an audience restriction that reflect that intention. The OpenID Connect
> ID Token is an example of that for browser based flows and the RFC 7523 JWT
> authorization grant is an example for non-browser flows.
>
> By implicit what I was trying to express are situations where a token that
> issued for a particular purpose (like a Facebook access token for access to
> Facebook APIs) is used implicitly for a different purpose (like getting a
> different access token for access to APIs in a different domain).
>
>
>
> On Fri, Dec 8, 2017 at 2:29 PM, Bill Burke  wrote:
>>
>> On Fri, Dec 8, 2017 at 12:41 PM, Brian Campbell
>>  wrote:
>> > I guess I'm going to kind of restate some of what I said in that earlier
>> > thread and a bit more. The access and refresh token URIs from the draft
>> > are
>> > intended to indicate that such tokens are issued by the given
>> > authorization
>> > server acting as the STS (perhaps this could be stated more clearly in
>> > the
>> > doc). As such, there isn't direct explicit support for OAuth access
>> > token to
>> > OAuth access token cross-domain type exchanges. That was intentional and
>> > I
>> > think is appropriate as I don't believe this draft should delve into
>> > pseudo
>> > federating access tokens and all the additional complexity and security
>> > implications that entails.
>>
>> I'll look in my email archives again, but, I wasn't convinced then
>> that there is all this additional complexity.
>>
>> > The assertion based authorization grants (RFCs
>> > 7523 & 7522) are intended to facilitate acquiring an access token from
>> > an
>> > external or cross-domain AS and I prefer that more explicit model for
>> > cross-domain than codifying a rather implicit way of doing it in token
>> > exchange.
>>
>> Not understanding what you mean by implicit vs. explicit.  I don't see
>> how what we've implemented is any more implicit than the current
>> specification.  If anything, I thought our impl was more explicit as
>> you can't derive the issuer from an opaque access token in the current
>> spec.
>>
>>
>> > A Facebook access token, for example, is issued to a client for
>> > delegated access to Facebook APIs. It isn't for delegated access to some
>> > other domain's APIs but an access token for access token exchange
>> > effectively turns it into that. And in some situations that can have
>> > problematic security implications.
>>
>> Internet applications trust Facebook, Google, whoever to identity and
>> authenticate users all the time and to grant access and permission
>> based on that identity.  An external exchange is just a non-browser
>> mechanism to facilitate this relationship.  For our IDP, our userbase
>> often use us as a broker between the various social websites and their
>> apps.  This way, apps don't care where the user was authenticated
>> from, they just see open id connect with a token format and domain
>> they control.  Developers often have apps that they are not able to
>> change how a user logs in or cannot unify their apps with a common
>> STS, token format, or even protocol.  Yet they still have a need to
>> make secure invocations across these domains and apps.
>>
>> > Big providers like Facebook have a lot of
>> > apps (OAuth clients) that can get access tokens. An organization might
>

Re: [OAUTH-WG] [token-exchange] Parameters to support external token exchange

[Bill Burke]

On Fri, Dec 8, 2017 at 12:41 PM, Brian Campbell
 wrote:
> I guess I'm going to kind of restate some of what I said in that earlier
> thread and a bit more. The access and refresh token URIs from the draft are
> intended to indicate that such tokens are issued by the given authorization
> server acting as the STS (perhaps this could be stated more clearly in the
> doc). As such, there isn't direct explicit support for OAuth access token to
> OAuth access token cross-domain type exchanges. That was intentional and I
> think is appropriate as I don't believe this draft should delve into pseudo
> federating access tokens and all the additional complexity and security
> implications that entails.

I'll look in my email archives again, but, I wasn't convinced then
that there is all this additional complexity.

> The assertion based authorization grants (RFCs
> 7523 & 7522) are intended to facilitate acquiring an access token from an
> external or cross-domain AS and I prefer that more explicit model for
> cross-domain than codifying a rather implicit way of doing it in token
> exchange.

Not understanding what you mean by implicit vs. explicit.  I don't see
how what we've implemented is any more implicit than the current
specification.  If anything, I thought our impl was more explicit as
you can't derive the issuer from an opaque access token in the current
spec.


> A Facebook access token, for example, is issued to a client for
> delegated access to Facebook APIs. It isn't for delegated access to some
> other domain's APIs but an access token for access token exchange
> effectively turns it into that. And in some situations that can have
> problematic security implications.

Internet applications trust Facebook, Google, whoever to identity and
authenticate users all the time and to grant access and permission
based on that identity.  An external exchange is just a non-browser
mechanism to facilitate this relationship.  For our IDP, our userbase
often use us as a broker between the various social websites and their
apps.  This way, apps don't care where the user was authenticated
from, they just see open id connect with a token format and domain
they control.  Developers often have apps that they are not able to
change how a user logs in or cannot unify their apps with a common
STS, token format, or even protocol.  Yet they still have a need to
make secure invocations across these domains and apps.

> Big providers like Facebook have a lot of
> apps (OAuth clients) that can get access tokens. An organization might well
> be okay with an app it controls exchanging a Facebook access token for an
> access token for its own APIs. But a 3rd party Facebook app (like maybe a
> new viral rate my '80's hairdo app) doing the same thing could be very
> problematic. It's not exactly the same thing but many of the same potential
> issues arise as when using OAuth for User Authentication. Standardization
> around access token for access token exchange would, at a minimum, need some
> real security analysis and recommendations/considerations.
>
> The token exchange draft went thought WGLC some time ago and is currently
> being written up by the document shepherd to send to the AD. It's close.
> It's been a long time coming and I'd really object to derailing it by making
> big additions to it at this late stage in the process.
>

That's fair enough.  I didn't know how far in the process the token
exchange draft was.  In the least, I wanted to make the WG aware of
our work.  We have a decent and growing user base with a problem
looking for a solution and we're going to get a lot of feedback on
what we've implemented.   At least from our open source project
perspective, there's a lot more interest in external exchange than
internal.  Which is why I'm posting this.


-- 
Bill Burke
Red Hat

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

[OAUTH-WG] [token-exchange] Parameters to support external token exchange

[Bill Burke]

The Keycloak project (oss idp), has implemented [1] the token exchange
draft (minus the actor token).  There's a couple of extensions we have
made to allow external token exchange to work.  I'd like to get some
consideration for these extensions to be added.  With proper
configurations, clients are able to exchange between different domains
and even social providers.  i.e. you can exchange a Facebook token for
a token issued by the IDP.

Here are the details:

We added a 'subject_issuer' parameter.  Many OAuth IDPs have opaque
access tokens and do not use JWTs for their access token (i.e.
Facebook and Google).  If the 'subject_token_type' is
'urn:ietf:params:oauth:token-type:access_token' and the access token
comes from an external provider, then the client must also pass a
'subject_issuer'.  The parameter value is something, anything that can
the IDP can resolve to an external provider.  How the validation of
this external token happens is implementation independent.

As I stated a few months back in an earlier email thread, I do not
think the 'audience' parameter would work for this type of external
exchange.  It is just too overloaded.  Additionally, I think it is
cleaner to specify an additional parameter rather than extracting
issuer information from the 'subject_token_type'.  You could do this,
but the spec would also have to define a URI scheme for
'subject_token_type' so that issuer information could be transmitted.

We also added a 'requested_issuer' parameter.  This allows the client
to request an external provider to obtain a token from.  Same reasons
and rules as 'subject_token_type'.

When 'requested_issuer' flow is done, user consent is often required
before the request issuer can issue a token for the user.  When this
is the case, a 400 response is returned with the following JSON
document:

{
   "error" : "",
   "error_description" : "..."
   "account-link-url" : "https://";
}

The error claim will be either token_expired or not_linked.  The
'account-link-url' claim is a link that the client can forward an user
agent to to obtain consent.  The client simply appends a
'redirect_uri' query parameter to this link and forwards the browser
for consent.  This 'redirect_uri' must be a registered and valid
redirect uri for the forwarding client.  After the redirect, the
client can then make an exchange request.  For error conditions, the
redirect_uri may by forwarded to with an additional 'error' query
parameter depending on whether the IDP deams it safe to do so.


Thanks,

Bill

[1] http://www.keycloak.org/docs/latest/securing_apps/index.html#_token-exchange

-- 
Bill Burke
Red Hat

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

Re: [OAUTH-WG] Token Exchange Implementations

[Bill Burke]

Red Hat has a partial implementation of this within the Keycloak project:

http://www.keycloak.org/docs/latest/securing_apps/index.html#_token-exchange

Been meaning to discuss this with this list as we added extensions to
better support external token exchange, specifically "subject_issuer"
and "requested_issuer" parameters.  We also did not add support for
actor tokens as we have not yet gotten requests for this level of
complexity.


On Thu, Nov 23, 2017 at 11:17 AM, Rifaat Shekh-Yusef
 wrote:
> All,
>
> As part of the write-up for the Token Exchange document, we are looking for
> information about implementation for this document.
>
> We are aware of 3 implementations for this document by: Salesforce,
> Microsoft, and Box.
>
> Are people aware of any other implementation?
>
> Regards,
>  Rifaat
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



-- 
Bill Burke
Red Hat

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

Re: [OAUTH-WG] Recommendations for browser-based apps

[Bill Burke]

Back to the OP...Why would browser Javascript implementing Authz Code
flow with public client be vulnerable?  Not understanding how an XSS
attack could work in such a scenario.

On Wed, Sep 20, 2017 at 3:22 AM, Jim Manico  wrote:
> PS: The RFC for SameSite cookies has moved to here.
> https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis
>
> It's an approved standard and was rolled into the new cookie RFC.
>
> Chrome support has a big impact on mobile and elsewhere. But I agree we need
> to see FireFox and Safari support and expect to see it within a year.
>
> But that should not stop folks from using it today. It's backwards
> compatible with existing cookie behavior and is quite beautiful in it's
> simplicity and power to defend against CSRF.
>
> Aloha,
> Jim
>
> On Sep 20, 2017, at 1:21 PM, Neil Madden  wrote:
>
> Is this growing in support? It seems like a good idea, but when I reviewed
> it recently the draft had expired almost a year ago and still only Chrome
> and Opera had implemented it. From the outside it looks as if it has
> (inexplicably) died. Do you know if there is some activity happening behind
> the scenes?
>
> -- Neil
>
> On 20 Sep 2017, at 02:31, Jim Manico  wrote:
>
> Not always, Bill. There is a new standard called "same site cookies" or
> "first party cookies" that allows you to programmatically remove this risk
> in some modern browsers, it's worth reviewing.
>
> https://tools.ietf.org/html/draft-west-first-party-cookies-07
>
> It's live in Chrome and Opera and will only grow in support.
> http://caniuse.com/#search=samesite
>
> Jim
>
>
> On Sep 20, 2017, at 8:44 AM, Bill Burke  wrote:
>
> Cookies are vulnerable to CXRF.
>
> On Tue, Sep 19, 2017 at 7:48 PM, nov matake  wrote:
>
> Why not using http-only cookies instead of refresh tokens?
>
> If the app can interact with AuthZ server through a hidden iframe with
>
> prompt=none param, you shouldn’t need refresh tokens.
>
>
> If your SAP is running on a different domain with the backend server,
>
> Safari’s Intelligent Tracking Prevention will break the hidden iframe way
>
> though.
>
>
> On Sep 20, 2017, at 7:32, John Bradley  wrote:
>
>
> Right,  Refresh token is bearer for native apps, that is why we came up with
>
> PKCE to protect code.
>
>
> For Angular the code flow with PKCE is probably better than the token
>
> response type.
>
>
> However with bearer tokens it is still riskier than code with a confidential
>
> client so the AS should take that into account and not allow refresh tokens
>
> to live forever.
>
>
> One future way to protect refresh tokens and perhaps Access tokens is to use
>
> token binding to bind the tokens to the user agent.   You could do that now
>
> for refresh tokens in Edge (Chrome has TB off by default still).
>
>
> I think more work needs to be done to come up with a best practice for SPA.
>
>
> John B.
>
>
> On Sep 19, 2017, at 7:02 PM, Adam Lewis 
>
> wrote:
>
>
> Only for confidential clients.  No authentication is required for public
>
> clients.
>
>
> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) 
>
> wrote:
>
>
> Except a refresh token is not purely bearer. The client is required to
>
> authenticate to use it.
>
>
> Phil
>
>
> On Sep 19, 2017, at 2:33 PM, Bill Burke  wrote:
>
>
> I'd be curious to the response to this too.
>
>
> Seems to me that refresh token has the same possible security risks in
>
> an Angular app as an access token, except the refresh token is valid
>
> longerStill, if you did the implicit flow, you'd have to have
>
> longer access token timeouts as it would be really annoying for the
>
> user to have to login again and again in a long session with your
>
> Angular app.
>
>
> We have a javascript adapter that does Authz Code Flow with PKCE for
>
> our Angular app.  It also does CORS checks on the code to token XHR
>
> request just in case on the IDP side.
>
>
> On Tue, Sep 19, 2017 at 9:27 AM, Stefan Büringer 
>
> wrote:
>
> Hi,
>
>
> there were some discussions in January regarding recommendations for
>
> browser-based apps
>
> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html).
>
>
> I'd just like to ask if the Authorization Code Flow with PKCE is a
>
> valid
>
> option for Single-Page-Applications (in our case Angular), because
>
> Implicit
>
> Flow cannot be used in our scenario.
>
>
> Authorization Code Flow with PKCE eliminates the necessity for client
>
> secrets, but our conc

Re: [OAUTH-WG] Recommendations for browser-based apps

[Bill Burke]

Cookies are vulnerable to CXRF.

On Tue, Sep 19, 2017 at 7:48 PM, nov matake  wrote:
> Why not using http-only cookies instead of refresh tokens?
> If the app can interact with AuthZ server through a hidden iframe with
> prompt=none param, you shouldn’t need refresh tokens.
>
> If your SAP is running on a different domain with the backend server,
> Safari’s Intelligent Tracking Prevention will break the hidden iframe way
> though.
>
> On Sep 20, 2017, at 7:32, John Bradley  wrote:
>
> Right,  Refresh token is bearer for native apps, that is why we came up with
> PKCE to protect code.
>
> For Angular the code flow with PKCE is probably better than the token
> response type.
>
> However with bearer tokens it is still riskier than code with a confidential
> client so the AS should take that into account and not allow refresh tokens
> to live forever.
>
> One future way to protect refresh tokens and perhaps Access tokens is to use
> token binding to bind the tokens to the user agent.   You could do that now
> for refresh tokens in Edge (Chrome has TB off by default still).
>
> I think more work needs to be done to come up with a best practice for SPA.
>
> John B.
>
> On Sep 19, 2017, at 7:02 PM, Adam Lewis 
> wrote:
>
> Only for confidential clients.  No authentication is required for public
> clients.
>
> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) 
> wrote:
>>
>> Except a refresh token is not purely bearer. The client is required to
>> authenticate to use it.
>>
>> Phil
>>
>> > On Sep 19, 2017, at 2:33 PM, Bill Burke  wrote:
>> >
>> > I'd be curious to the response to this too.
>> >
>> > Seems to me that refresh token has the same possible security risks in
>> > an Angular app as an access token, except the refresh token is valid
>> > longerStill, if you did the implicit flow, you'd have to have
>> > longer access token timeouts as it would be really annoying for the
>> > user to have to login again and again in a long session with your
>> > Angular app.
>> >
>> > We have a javascript adapter that does Authz Code Flow with PKCE for
>> > our Angular app.  It also does CORS checks on the code to token XHR
>> > request just in case on the IDP side.
>> >
>> >> On Tue, Sep 19, 2017 at 9:27 AM, Stefan Büringer 
>> >> wrote:
>> >> Hi,
>> >>
>> >> there were some discussions in January regarding recommendations for
>> >> browser-based apps
>> >> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html).
>> >>
>> >> I'd just like to ask if the Authorization Code Flow with PKCE is a
>> >> valid
>> >> option for Single-Page-Applications (in our case Angular), because
>> >> Implicit
>> >> Flow cannot be used in our scenario.
>> >>
>> >> Authorization Code Flow with PKCE eliminates the necessity for client
>> >> secrets, but our concern is that exposing the refresh token to the SPA
>> >> might
>> >> be a security risk, compared to the Implicit Flow were no refresh token
>> >> is
>> >> exposed.
>> >>
>> >> What's your take on this?
>> >>
>> >> Kind regards,
>> >> Stefan Büringer
>> >>
>> >> P.S. I couldn't find that much on the internet regarding Authorization
>> >> Code
>> >> Flow with PKCE in SPAs, if you have some recommendations for good blog
>> >> posts
>> >> I would be grateful.
>> >>
>> >> ___
>> >> OAuth mailing list
>> >> OAuth@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/oauth
>> >>
>> >
>> >
>> >
>> > --
>> > Bill Burke
>> > Red Hat
>> >
>> > ___
>> > 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
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



-- 
Bill Burke
Red Hat

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

Re: [OAUTH-WG] Recommendations for browser-based apps

[Bill Burke]

I'd be curious to the response to this too.

Seems to me that refresh token has the same possible security risks in
an Angular app as an access token, except the refresh token is valid
longerStill, if you did the implicit flow, you'd have to have
longer access token timeouts as it would be really annoying for the
user to have to login again and again in a long session with your
Angular app.

We have a javascript adapter that does Authz Code Flow with PKCE for
our Angular app.  It also does CORS checks on the code to token XHR
request just in case on the IDP side.

On Tue, Sep 19, 2017 at 9:27 AM, Stefan Büringer  wrote:
> Hi,
>
> there were some discussions in January regarding recommendations for
> browser-based apps
> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html).
>
> I'd just like to ask if the Authorization Code Flow with PKCE is a valid
> option for Single-Page-Applications (in our case Angular), because Implicit
> Flow cannot be used in our scenario.
>
> Authorization Code Flow with PKCE eliminates the necessity for client
> secrets, but our concern is that exposing the refresh token to the SPA might
> be a security risk, compared to the Implicit Flow were no refresh token is
> exposed.
>
> What's your take on this?
>
> Kind regards,
> Stefan Büringer
>
> P.S. I couldn't find that much on the internet regarding Authorization Code
> Flow with PKCE in SPAs, if you have some recommendations for good blog posts
> I would be grateful.
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



-- 
Bill Burke
Red Hat

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

Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains

[Bill Burke]

So, you're saying the STS has to define a subject_type for each external 
token the client wants to exchange from?  A type that is potentially 
proprietary and different between each and every STS? On the opposite 
end, when you want to convert to an external token, the STS either has 3 
options for the client to specify that it wants an external token.  1) a 
proprietary response type, 2) a proprietary resource scheme, 3) a 
proprietary audience scheme.


Don't you think at minimum, the token-exchange spec should define a 
standard way to do OAuth to OAuth cross-domain exchanges?  Right now 
cross-domain exchanges are proprietary and completely up to the target 
STS on how it wants the client to formulate a cross-domain exchange.  I 
still think a "subject_issuer" and "requested_issuer" are the clearest 
and simplest way to enable such an interaction.



On 7/28/17 6:28 PM, Brian Campbell wrote:
The urn:ietf:params:oauth:token-type:access_token type is an 
"indicator that the token is a typical OAuth access token issued by 
the authorization server in question" (see near the end of section 3 
<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-3>) 
so the issuer is the given STS in that case. Cross domain is possible 
by use of other token types that are not opaque to the STS where the 
issuer can be inferred from the token.


On Fri, Jul 28, 2017 at 3:27 PM, Bill Burke <mailto:bbu...@redhat.com>> wrote:


Thanks for replying,

The Introduction of the spec implies that inter-security-domain
exchange is supported: "

  A Security Token Service (STS) is a service capable of validating and
issuing security tokens, which enables clients to obtain appropriate
access credentials for resources in heterogeneous environments or
across security domains.
"

But with the current API if you want to exchange an external token to an 
internal one, there is no way for the STS to identify where the subject_token 
originated.  Are you saying that an STS cannot accept tokens from an external 
domain?

i.e

subject_token: 

subject_token_type: urn:ietf:params:oauth:token-type:access-token

There's just no way for the STS to know where the subject_token
came from because the subject_token can be completely opaque.

Now, on the flip side, if you are converting from an internal
token to an external one, the audience parameter is just too
undefined.  For example, how could you specify that you want a
token for an external client of an external issuer.  Client ids
are opaque in OAuth, and issuer id isn't even something that is
defined at all.  In OpenID connect, an issuer id can be any URL.

IMO, adding optional "subject_token_issuer" and "requested_issuer"
parameters only clarifies and simplifies the cross-domain case.  
If you don't like "issuer" maybe "domain" is a better word?


Thanks for replying,

Bill





On 7/28/17 4:39 PM, Brian Campbell wrote:

In general, an instance of an AS/STS can only issue tokens from
itself. The audience/resource parameters tell the AS/STS where
the requested token will be used, which will influence the
audience of the token (and maybe other aspects). But the issuer
of the requested token will be the AS/STS that issued it. A cross
domain exchange could happen by a client presenting a
subject_token from a different domain/issuer (that the AS/STS
trusts) and receiving a token issued by that AS/STS suitable for
the target domain.



On Fri, Jul 28, 2017 at 9:06 AM, Bill Burke mailto:bbu...@redhat.com>> wrote:

Should probably have a "subject_issuer" and "actor_issuer" as
well as the "requested_issuer" too.

FYI, I'm actually applying this spec to write a token
exchange service to connect various product stacks that have
different and often proprietary token formats and architectures.



On 7/26/17 6:44 PM, Bill Burke wrote:

Hi all,

I'm looking at Draft 9 of the token-exchange spec.  How
would one build a request to:

* exchange a token issued by a different domain to a
client managed by the authorization server.

* exchange a token issued by the authorization server
(the STS) for a token of a different issuer and different
client.  In other words, for a token targeted to a
specific client in a different authorization server or
realm or domain or whatever you want to call it.

* exchange a token issued by a different issuer for a
token of a different issuer and client.

Is the spec missing something like a "requested_issuer"
identifie

Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains

[Bill Burke]

Thanks for replying,

The Introduction of the spec implies that inter-security-domain exchange 
is supported: "


 A Security Token Service (STS) is a service capable of validating and
   issuing security tokens, which enables clients to obtain appropriate
   access credentials for resources in heterogeneous environments or
   across security domains.
"

But with the current API if you want to exchange an external token to an 
internal one, there is no way for the STS to identify where the subject_token 
originated.  Are you saying that an STS cannot accept tokens from an external 
domain?

i.e

subject_token: 

subject_token_type: urn:ietf:params:oauth:token-type:access-token

There's just no way for the STS to know where the subject_token came 
from because the subject_token can be completely opaque.


Now, on the flip side, if you are converting from an internal token to 
an external one, the audience parameter is just too undefined.  For 
example, how could you specify that you want a token for an external 
client of an external issuer.  Client ids are opaque in OAuth, and 
issuer id isn't even something that is defined at all.  In OpenID 
connect, an issuer id can be any URL.


IMO, adding optional "subject_token_issuer" and "requested_issuer" 
parameters only clarifies and simplifies the cross-domain case.   If you 
don't like "issuer" maybe "domain" is a better word?


Thanks for replying,

Bill





On 7/28/17 4:39 PM, Brian Campbell wrote:
In general, an instance of an AS/STS can only issue tokens from 
itself. The audience/resource parameters tell the AS/STS where the 
requested token will be used, which will influence the audience of the 
token (and maybe other aspects). But the issuer of the requested token 
will be the AS/STS that issued it. A cross domain exchange could 
happen by a client presenting a subject_token from a different 
domain/issuer (that the AS/STS trusts) and receiving a token issued by 
that AS/STS suitable for the target domain.




On Fri, Jul 28, 2017 at 9:06 AM, Bill Burke <mailto:bbu...@redhat.com>> wrote:


Should probably have a "subject_issuer" and "actor_issuer" as well
as the "requested_issuer" too.

FYI, I'm actually applying this spec to write a token exchange
service to connect various product stacks that have different and
often proprietary token formats and architectures.



On 7/26/17 6:44 PM, Bill Burke wrote:

Hi all,

I'm looking at Draft 9 of the token-exchange spec. How would
one build a request to:

* exchange a token issued by a different domain to a client
managed by the authorization server.

* exchange a token issued by the authorization server (the
STS) for a token of a different issuer and different client. 
In other words, for a token targeted to a specific client in a

different authorization server or realm or domain or whatever
you want to call it.

* exchange a token issued by a different issuer for a token of
a different issuer and client.

Is the spec missing something like a "requested_issuer"
identifier?  Seems that audience is too opaque of a parameter
for the authz server to determine how to exchange the token.

Thanks,

Bill



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



/CONFIDENTIALITY NOTICE: This email may contain confidential and 
privileged material for the sole use of the intended recipient(s). Any 
review, use, distribution or disclosure by others is strictly 
prohibited.  If you have received this communication in error, please 
notify the sender immediately by e-mail and delete the message and any 
file attachments from your computer. Thank you./ 


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

Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains

[Bill Burke]

Should probably have a "subject_issuer" and "actor_issuer" as well as 
the "requested_issuer" too.


FYI, I'm actually applying this spec to write a token exchange service 
to connect various product stacks that have different and often 
proprietary token formats and architectures.



On 7/26/17 6:44 PM, Bill Burke wrote:

Hi all,

I'm looking at Draft 9 of the token-exchange spec.  How would one 
build a request to:


* exchange a token issued by a different domain to a client managed by 
the authorization server.


* exchange a token issued by the authorization server (the STS) for a 
token of a different issuer and different client.  In other words, for 
a token targeted to a specific client in a different authorization 
server or realm or domain or whatever you want to call it.


* exchange a token issued by a different issuer for a token of a 
different issuer and client.


Is the spec missing something like a "requested_issuer" identifier?  
Seems that audience is too opaque of a parameter for the authz server 
to determine how to exchange the token.


Thanks,

Bill



___
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] [token-exchange] exchanging between issuers/domains

[Bill Burke]

Hi all,

I'm looking at Draft 9 of the token-exchange spec.  How would one build 
a request to:


* exchange a token issued by a different domain to a client managed by 
the authorization server.


* exchange a token issued by the authorization server (the STS) for a 
token of a different issuer and different client.  In other words, for a 
token targeted to a specific client in a different authorization server 
or realm or domain or whatever you want to call it.


* exchange a token issued by a different issuer for a token of a 
different issuer and client.


Is the spec missing something like a "requested_issuer" identifier?  
Seems that audience is too opaque of a parameter for the authz server to 
determine how to exchange the token.


Thanks,

Bill



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

Re: [OAUTH-WG] Short lived access token and no refresh token

[Bill Burke]

For browser apps, implicit flow provides an access token but no refresh 
token.  For non-browser apps only client credentials grant doesn't 
supply a refresh token.  As for token access times, I believe only 
extensions to OAuth define those types of capabilities.  i.e. OpenID 
Connect defines a "max-age" claim that you can pass when requesting a token.



On 7/25/17 10:48 AM, Saurav Sarkar wrote:

Hi All,

We have a scenario where one of our stakeholder wants to mandatorily 
initiate the authentication at certain point of time.


As per 
https://www.oauth.com/oauth2-servers/access-tokens/access-token-lifetime/
there can be an option where access token is set for certain time and 
refresh token is not set. So we want to explore this option for this 
scenario.


I have couple of questions regarding this

(a) Is this  option part of OAuth 2 specification ? If yes can you 
please point me to the exact IETF link ?


(b) Is there any other way our scenario can be achieved ? We want this 
scenario to be supported from the authorization server (platform) 
itself and not in the client app or resource server.


Thanks and Best Regards,
Saurav


___
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] oauth with command line clients

[Bill Burke]

I guess the auth code flow could be used with the command line tool 
using the OpenID Connect "display" parameter with a value of 
"command-line" or "text" or something when it makes its auth request.  I 
could go the route of defining what "command-line" display value would 
mean in OIDC land.  Awkward from an implementation point of view, but a 
viable path.


Quite honestly, I just dont' see how any app developer would want to 
require device flow.  It is a bad user experience.  I would even go as 
far to say that the device flow is an unacceptable user experience.  
Especially if cut and paste is not possible and the human has to enter 
in some kind of long cryptic code by hand.





On 6/12/17 2:34 PM, Phil Hunt wrote:

+1

The point of OAuth is to break away from using UID/Password (basic auth).

The device flow is the best way to allow stronger authentication of 
the authorizing user while still allowing a limited input device (e.g. 
command line) to work.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>

On Jun 12, 2017, at 11:22 AM, Justin Richer <mailto:jric...@mit.edu>> wrote:


I second the recommendation to use the device flow for this kind of 
system. The commandline client would print out a text string for the 
user to enter into their browser elsewhere.


If you can pop up a system browser then it's even easier and you can 
just use the auth code flow, but it's a lot to assume that a 
commandline app can have that kind of capability available to it. 
Printing out a string? That's easy and universal. That's why I say go 
with the device flow.


The thing is, at the end of the day, you need the user to 
authenticate to the AS if you're going to get delegated access from 
them. That's really the whole point of the OAuth protocol, after all. 
So you can either do that in a local browser of some kind (like 
popping a system browser), on another device (with the device flow), 
or you can be evil and use the username/password grant and just steal 
the user's credentials yourself. If it's not clear, I don't recommend 
that, basically ever.


 -- Justin


On 6/11/2017 11:58 PM, Aaron Parecki wrote:

I've seen this done a few ways:

* The Device Flow: 
https://tools.ietf.org/html/draft-ietf-oauth-device-flow 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Ddevice-2Dflow&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=gWeHcqrhQt-ijJ5-UXHxML5rMtR05GjKVyxqZBEeQAM&e=> 
which is what you see on browserless devices like the Apple TV 
logging in to a cable provider from your phone. A short code is 
generated and displayed on the screen, you launch a browser on your 
phone and enter the code. This would work just as well from the 
command line on the same device.
* I've also seen apps use the authorization flow, by displaying the 
authorization URL on the command line prompt and instructing the 
user to open it in a browser. The redirect URI is a hosted web page 
that displays the authorization code and instructs the user to paste 
it back at the terminal.
* The command line app can launch an HTTP server on localhost and 
use that as the redirect URL for the authorization code flow. This 
option ends up being the most seamless since it works like a 
traditional flow without any special instructions to the user.



Aaron Parecki
aaronparecki.com 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__aaronparecki.com&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=Zn85klv9a00I3Uo74zgqAelgrFUFQc72PdFwg4gkECQ&e=>
@aaronpk 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_aaronpk&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=g5RjhR9W1VYt00S4dV0t9ijZ4gC4HE93waQ_t7mUzUs&e=>



On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke <mailto:bbu...@redhat.com>> wrote:


Has anybody done any spec work around doing oauth from command
line interfaces?  We're looking for something where the auth
server can generate text-based challenges that are rendered in
the console window that query for simple text input over
possibly multiple requests.  I'm not talking about Resource
Owner or Client Credentials grant.  The command line client may
not know the credential types required for a successful token
    request. It would 

Re: [OAUTH-WG] oauth with command line clients

[Bill Burke]

On 6/12/17 12:20 PM, David Waite wrote:
FYI, A few years ago I did a demonstration on OpenID Connect at Cloud 
Identity Summit using a collection of bash scripts and command-line 
utilities (nc, jq). I used the macOS system command ‘open’ to launch a 
browser, and netcat to field the response as a poor man’s HTTP 
endpoint.  The code for that presentation is at 
https://github.com/dwaite/Presentation-Code-OpenID-Connect-Dynamic-Client-Registration 



A few options for the user challenge/consent portion of the 
authentication are:


- use non-HTML request/response API (around some custom MIME type) to 
drive a user agent through the authentication/scope approval/etc 
stages of your AS
This is the option I'm interested in.  Something simple around 401 
challenges, text/plain mime type, and simple stdin processing.  I"ll 
post what I'm thinking of if its appropriate.  A colleague pointed me to 
SASL + HTTP [1], but not sure if that's what I'm looking for.


Thanks everybody,

Bill

[1] https://tools.ietf.org/html/draft-nystrom-http-sasl-09


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

Re: [OAUTH-WG] oauth with command line clients

[Bill Burke]

I've read about these techniques, but, its just not a good user 
experience.  I'm thinking more of something where the command line 
console is the sole user agent and the auth server drives a plain text 
based interaction much like an HTTP Server drives interaction with HTML 
and the browser.


This isn't anything complex.  It should be a simple protocol, but I'd 
like to piggy back on existing solutions to build some consensus around 
what I think is a common issue with using OAuth. If there isn't anything 
going on here in the OAuth group surrounding this, would be willing to 
draw up a Draft if there is interest.



On 6/11/17 11:58 PM, Aaron Parecki wrote:

I've seen this done a few ways:

* The Device Flow: 
https://tools.ietf.org/html/draft-ietf-oauth-device-flow which is what 
you see on browserless devices like the Apple TV logging in to a cable 
provider from your phone. A short code is generated and displayed on 
the screen, you launch a browser on your phone and enter the code. 
This would work just as well from the command line on the same device.
* I've also seen apps use the authorization flow, by displaying the 
authorization URL on the command line prompt and instructing the user 
to open it in a browser. The redirect URI is a hosted web page that 
displays the authorization code and instructs the user to paste it 
back at the terminal.
* The command line app can launch an HTTP server on localhost and use 
that as the redirect URL for the authorization code flow. This option 
ends up being the most seamless since it works like a traditional flow 
without any special instructions to the user.



Aaron Parecki
aaronparecki.com <http://aaronparecki.com>
@aaronpk <http://twitter.com/aaronpk>


On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke <mailto:bbu...@redhat.com>> wrote:


Has anybody done any spec work around doing oauth from command
line interfaces?  We're looking for something where the auth
server can generate text-based challenges that are rendered in the
console window that query for simple text input over possibly
multiple requests.  I'm not talking about Resource Owner or Client
Credentials grant.  The command line client may not know the
credential types required for a successful token request. It would
be easy to write a simple protocol, but I'd rather just do
something around any existing internet draft or rfc that somebody
has put some thought into.  Hope I'm making sense here.

Thanks,

Bill Burke

Red Hat

___
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] oauth with command line clients

[Bill Burke]

Has anybody done any spec work around doing oauth from command line 
interfaces?  We're looking for something where the auth server can 
generate text-based challenges that are rendered in the console window 
that query for simple text input over possibly multiple requests.  I'm 
not talking about Resource Owner or Client Credentials grant.  The 
command line client may not know the credential types required for a 
successful token request. It would be easy to write a simple protocol, 
but I'd rather just do something around any existing internet draft or 
rfc that somebody has put some thought into.  Hope I'm making sense here.


Thanks,

Bill Burke

Red Hat

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

Re: [OAUTH-WG] Google's use of Implicit Grant Flow

[Bill Burke]

For our IDP [1], our javascript library uses the auth code flow, but 
requires a public client, redirect_uri validation, and also does CORS 
checks and processing.  We did not like Implicit Flow because


1) access tokens would be in the browser history

2) short lived access tokens (seconds or minutes) would require a 
browser redirect


I'd be really curious to hear other's thoughts though.

[1] http://keycloak.org




On 2/16/17 5:44 PM, Jim Manico wrote:


Hello Folks,

I noticed that Google supports the OAuth 2 Implicit flow for 
third-party JavaScript applications.


https://developers.google.com/identity/protocols/OAuth2UserAgent

Isn't this generally discouraged from a security POV? *Is there a 
better OAuth 2 flow for third party SPA applications?*


Aloha,
--
Jim Manico
Manicode Security
https://www.manicode.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] redircet_uri matching algorithm

[Bill Burke]

On 5/20/2015 1:37 PM, David Waite wrote:



On May 16, 2015, at 1:43 AM, Patrick Gansterer  wrote:

"OAuth 2.0 Dynamic Client Registration Protocol” [1] is nearly finished and 
provides the possibility to register additional “Client Metadata”.

OAuth 2.0 does not define any matching algorithm for the redirect_uris. The 
latest information on that topic I could find is [1], which is 5 years old. Is 
there any more recent discussion about it?

I’d suggest to add an OPTIONAL “redirect_uris_matching_method” client metadata. 
Possible valid values could be:
* “exact”: The “redirect_uri" provided in a redirect-based flow must match 
exactly one of of the provided strings in the “redirect_uris” array.
* “prefix”: The "redirect_uri" must begin with one of the “redirect_uris”. (e.g. 
"http://example.com/path/subpath” would be valid with [“http://example.com/path/“, 
“http://example.com/otherpath/”])
* “regex”: The provided “redirect_uris” are threatened as regular expressions, 
which the “redirect_uri” will be matched against. (e.g. 
“http://subdomain.example.com/path5/“ would be valid with 
[“^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/“]


I don’t know if this is appropriate. For example, If a server is unwilling to 
support arbitrary regex matching, how would a client which required this be 
able to register dynamically? Or conversely: if a client did not require regex 
matching, why would they request this from a server?

If a client requests regex or prefix, it was built to rely on these to work. If 
some set of servers choose not to support regex or prefix for scope or security 
reasons, this hurts interoperability from the perspective of dynamic 
registration. And we already have a workaround - instead make your client rely 
on the state parameter.

A client doing code or implicit should specify exact return URLs in their 
registration, and if they need to send the user someplace else after 
authentication it should be represented to the client by their state param.



Nice workaround, but you are then making the client more difficult to 
implement and the state param larger and more complex.  prefix matching 
seems like it would be a very common thing that an auth server supports 
and clients would want to have.




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

Re: [OAUTH-WG] OAuth Token Swap (token chaining)

[Bill Burke]

On 3/24/2015 8:55 AM, Brian Campbell wrote:

And here's the somewhat different take on token exchange that I
mentioned yesterday:
https://tools.ietf.org/html/draft-campbell-oauth-sts-01



I'm unclear how your STS would work.  Is your client required to go 
through the whole OAuth process to obtain an access token on behalf of 
the user before it can invoke on the STS?  Or can it be granted tokens 
for any user out of band without user consent or user authorization?



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

Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

[Bill Burke]

that might be a privacy issue, but we don’t
allow it.
 >>
 >>
 >> Thanks, John.  It may be helpful to add in this explanation unless
 >> there is some reason not to?
 >>
 >>
 >> John B.
 >>
 >>
 >>
 >>
 >> --
 >>
 >> Best regards,
 >> Kathleen
 >> ___
 >> OAuth mailing list
 >> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto: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
 >



--

Best regards,

Kathleen



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



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

Re: [OAUTH-WG] user impersonation protocol?

[Bill Burke]

Yeah, I know its risky, but that's the requirement.  Was just wondering 
if there was any protocol work being done around it, so that we could 
avoid doing a lot of the legwork to make it safe/effective.  Currently 
for us, we need to do this between two separate IDPs, which is where the 
protocol work comes in...If it was just a single IDP managing 
everything, then it would just be an internal custom IDP feature.


Thanks all.



On 2/16/2015 12:37 AM, Bill Mills wrote:

User impersonation is very very risky.  The legal aspects of it must be
considered.  There's a lot of work to do to make it safe/effective.

Issuing a scoped token that allows ready only access can work with the
above caveats.  Then properties/componenets have to explicitly support
the new scope and do the right thing.


On Sunday, February 15, 2015 8:34 PM, Justin Richer  wrote:


For this case you'd want to be very careful about who was able to do
such impersonation, obviously, but it's doable today with custom IdP
behavior. You can simply use OpenID Connect and have the IdP issue an id
token for the target user instead of the "actual" current user account.

I would also suggest considering adding a custom claim to the id token
to indicate this is taking place. That way you can differentiate where
needed, including in logs.

-- Justin

/ Sent from my phone /


 Original message 
From: Bill Burke 
Date:02/15/2015 10:55 PM (GMT-05:00)
To: oauth 
Cc:
Subject: [OAUTH-WG] user impersonation protocol?

We have a case where we want to allow a logged in admin user to
impersonate another user so that they can visit differents browser apps
as that user (So they can see everything that the user sees through
their browser).

Anybody know of any protocol work being done here in the OAuth group or
some other IETF or even Connect effort that would support something like
this?

Thanks,

Bill

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




--
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-WG] user impersonation protocol?

[Bill Burke]

We have a case where we want to allow a logged in admin user to 
impersonate another user so that they can visit differents browser apps 
as that user (So they can see everything that the user sees through 
their browser).


Anybody know of any protocol work being done here in the OAuth group or 
some other IETF or even Connect effort that would support something like 
this?


Thanks,

Bill

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

Re: [OAUTH-WG] Confusion on Implicit Grant flow

[Bill Burke]

On 2/10/2015 8:15 AM, John Bradley wrote:

The issue is maintaining key material in the browser.

Web Crypto will help with that , but is not deployed widely in browsers at the 
moment.

Thinking about it a bit someone could make a more secure flow for JS clients 
using code and some Connect extensions now.

If I were concerned about logging the AT, then I would have the JS make a CORS 
call to the authorization endpoint with:
response_type=code+id_token  
[http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html]
code_challenge=(challenge value)[ 
https://tools.ietf.org/html/draft-ietf-oauth-spop-02]
code_challenge_method=S256



Excellent.  Thanks.



In Connect the JS client crates a nonce value and sends that with the request.  
That value comes back in the signed_id token allowing the JS to know that the 
code and id_token are in reply to it's request and not replayed from another 
session.



Why would you need the nonce if the IDP guarantees that the code can 
only be used once?  The code, state, and redirect-uri are all validated 
by the IDP with the access token request.


Bill

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

Re: [OAUTH-WG] Confusion on Implicit Grant flow

[Bill Burke]

On 2/10/2015 7:06 AM, Brian Campbell wrote:



On Mon, Feb 9, 2015 at 3:59 PM, John Bradley mailto:ve7...@ve7jtb.com>> wrote:

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


Actually response_mode is defined in that spec itself in section 2.1
<http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#ResponseModes>.



Yeah, and it looks like you can use it for anything.  It only defines 
default modes for various response types (code, token, etc.)


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

Re: [OAUTH-WG] Confusion on Implicit Grant flow

[Bill Burke]

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

Re: [OAUTH-WG] Confusion on Implicit Grant flow

[Bill Burke]

For implicit flow, wouldn't the token be available in the browser 
history and could also possibly be bookmarked by accident or on purpose? 
 If a code is bookmarked, so what?  It is only valid for a tiny window 
(milliseconds).


Please tell me how a code is more likely to be leaked without a client 
secret when it can only be sent via SSL to a validated URL.



On 2/9/2015 4:02 PM, John Bradley wrote:

You are passing code in a query parameter, and without a secret that is more 
likely to be leaked than sending token in the fragment directly from the 
authorization endpoint to the browser JS in a fragment.

You have several extra round trips for no security benefit.   In your case the 
code in the query parameter goes from the browser to the redirect endpoint then 
must be sent back to the browser, and then to the token endpoint.

So yes using code for that is less secure.

Both rely solely on the registered redirect URI for security, but implicit has 
fewer hopes and is more friendly to JS.

John B.

On Feb 9, 2015, at 5:50 PM, Bill Burke  wrote:

If you don't have a client secret, why is Javascript-based auth code grant flow 
more risky?  We also require SSL and valid redirect URI patterns to be 
registered for the application.  The code can only ever be sent to specific 
URLs and can only be used once.  CORS origin validation is also an extra step 
we do to ensure a rogue javascript app isn't making any code-to-token requests.

I'm just trying to figure out if we missed anything...

On 2/9/2015 3:16 PM, John Bradley wrote:

If you don't have a client secret, or are storing the the client secret in the 
Javascrypt, then you are probably more at risk using code than implicit.

Implicit is risky because running a OAuth client in the browser is risky.  
Using code in that case makes it no better, and arguably worse.

Perhaps I don't understand the environment.

John B.


On Feb 9, 2015, at 5:05 PM, Bill Burke  wrote:

Due to the security risks of implicit Grant flow, our Javascript adapter only 
supports  Auth Code Grant flow.  Our IDP has an extra step of allowing you to 
specify a valid CORS origin for an application.  Anybody see any problems with 
this kind of approach?  Implicit Grant Flow just seemed really risky to even 
support as a protocol.


On 2/6/2015 4:40 PM, Josh Mandel wrote:

Hi Adam,

I'm not 100% sure what you're envisioning as an alternative to the
implicit flow, but if I'm reading between the lines of your question
correctly, there are two key parts to the answer, because the implicit
flow is designed to accomplish two key goals (vs. the authorization code
grant):

1. Shave off one round-trip HTTP request (the step of exchanging a code
for a token)
2. Avoid unnecessarily leading the token to the client's back-end web server

Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes
advantage of the fact that a URL's "#hash" is not sent to the server
with an HTTP request. By embedding the token in a "#hash", it won't
inadvertently appear in server logs, for example. So with the implicit
flow, I can (for example) statically host a browser-based app at Amazon
S3 without having access tokens leak to Amazon. (Of course, if your
threat model includes a compromised server, then bets are off on this
point.)

Hope this helps,

   -Josh



On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis
mailto:adam.le...@motorolasolutions.com>> wrote:

Hi,

__ __

Having spent most of my time with native apps and web apps, I now am
looking at use cases where I need to implement a user-agent-based
app.  The Implicit flow seems to be optimized for this.

__ __

To test my understanding, this flow is for a JavaScript client (or
similar) executing within a web browser.

__ __

At step (a) the client directs the UA to the authorization server,
but the authorization server redirects the UA to a web-hosted client
resource.  Why?  It says so that the web-hosted client resources can
push javascript (or other) back into the UA so it can extract the
access token in the fragment; but some sort of javascript is already
running in the browser, since it initiated the authorization request
in the first place.  So why this extra step?  Why not treat the
javascript client running in the UA like a native app and handle the
redirect uri?

__ __

I know this was well thought out when the spec was written, so
trying to figure out what I’m missing?

__ __

__ __

__ __

Tx!
adam


___
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



--
Bill Burke
JBoss, a divisi

Re: [OAUTH-WG] Confusion on Implicit Grant flow

[Bill Burke]

If you don't have a client secret, why is Javascript-based auth code 
grant flow more risky?  We also require SSL and valid redirect URI 
patterns to be registered for the application.  The code can only ever 
be sent to specific URLs and can only be used once.  CORS origin 
validation is also an extra step we do to ensure a rogue javascript app 
isn't making any code-to-token requests.


I'm just trying to figure out if we missed anything...

On 2/9/2015 3:16 PM, John Bradley wrote:

If you don't have a client secret, or are storing the the client secret in the 
Javascrypt, then you are probably more at risk using code than implicit.

Implicit is risky because running a OAuth client in the browser is risky.  
Using code in that case makes it no better, and arguably worse.

Perhaps I don't understand the environment.

John B.


On Feb 9, 2015, at 5:05 PM, Bill Burke  wrote:

Due to the security risks of implicit Grant flow, our Javascript adapter only 
supports  Auth Code Grant flow.  Our IDP has an extra step of allowing you to 
specify a valid CORS origin for an application.  Anybody see any problems with 
this kind of approach?  Implicit Grant Flow just seemed really risky to even 
support as a protocol.


On 2/6/2015 4:40 PM, Josh Mandel wrote:

Hi Adam,

I'm not 100% sure what you're envisioning as an alternative to the
implicit flow, but if I'm reading between the lines of your question
correctly, there are two key parts to the answer, because the implicit
flow is designed to accomplish two key goals (vs. the authorization code
grant):

1. Shave off one round-trip HTTP request (the step of exchanging a code
for a token)
2. Avoid unnecessarily leading the token to the client's back-end web server

Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes
advantage of the fact that a URL's "#hash" is not sent to the server
with an HTTP request. By embedding the token in a "#hash", it won't
inadvertently appear in server logs, for example. So with the implicit
flow, I can (for example) statically host a browser-based app at Amazon
S3 without having access tokens leak to Amazon. (Of course, if your
threat model includes a compromised server, then bets are off on this
point.)

Hope this helps,

   -Josh



On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis
mailto:adam.le...@motorolasolutions.com>> wrote:

Hi,

__ __

Having spent most of my time with native apps and web apps, I now am
looking at use cases where I need to implement a user-agent-based
app.  The Implicit flow seems to be optimized for this.

__ __

To test my understanding, this flow is for a JavaScript client (or
similar) executing within a web browser.

__ __

At step (a) the client directs the UA to the authorization server,
but the authorization server redirects the UA to a web-hosted client
resource.  Why?  It says so that the web-hosted client resources can
push javascript (or other) back into the UA so it can extract the
access token in the fragment; but some sort of javascript is already
running in the browser, since it initiated the authorization request
in the first place.  So why this extra step?  Why not treat the
javascript client running in the UA like a native app and handle the
redirect uri?

__ __

I know this was well thought out when the spec was written, so
trying to figure out what I’m missing?

__ __

__ __

__ __

Tx!
adam


___
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



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




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

Re: [OAUTH-WG] Confusion on Implicit Grant flow

[Bill Burke]

Due to the security risks of implicit Grant flow, our Javascript adapter 
only supports  Auth Code Grant flow.  Our IDP has an extra step of 
allowing you to specify a valid CORS origin for an application.  Anybody 
see any problems with this kind of approach?  Implicit Grant Flow just 
seemed really risky to even support as a protocol.



On 2/6/2015 4:40 PM, Josh Mandel wrote:

Hi Adam,

I'm not 100% sure what you're envisioning as an alternative to the
implicit flow, but if I'm reading between the lines of your question
correctly, there are two key parts to the answer, because the implicit
flow is designed to accomplish two key goals (vs. the authorization code
grant):

1. Shave off one round-trip HTTP request (the step of exchanging a code
for a token)
2. Avoid unnecessarily leading the token to the client's back-end web server

Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes
advantage of the fact that a URL's "#hash" is not sent to the server
with an HTTP request. By embedding the token in a "#hash", it won't
inadvertently appear in server logs, for example. So with the implicit
flow, I can (for example) statically host a browser-based app at Amazon
S3 without having access tokens leak to Amazon. (Of course, if your
threat model includes a compromised server, then bets are off on this
point.)

Hope this helps,

   -Josh



On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis
mailto:adam.le...@motorolasolutions.com>> wrote:

Hi,

__ __

Having spent most of my time with native apps and web apps, I now am
looking at use cases where I need to implement a user-agent-based
app.  The Implicit flow seems to be optimized for this.

__ __

To test my understanding, this flow is for a JavaScript client (or
similar) executing within a web browser.

__ __

At step (a) the client directs the UA to the authorization server,
but the authorization server redirects the UA to a web-hosted client
resource.  Why?  It says so that the web-hosted client resources can
push javascript (or other) back into the UA so it can extract the
access token in the fragment; but some sort of javascript is already
running in the browser, since it initiated the authorization request
in the first place.  So why this extra step?  Why not treat the
javascript client running in the UA like a native app and handle the
redirect uri?

__ __

I know this was well thought out when the spec was written, so
trying to figure out what I’m missing?

__ __

__ __

__ __

Tx!
adam


___
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



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

Re: [OAUTH-WG] open redirect in rfc6749

[Bill Burke]

,

my understanding is that there is a rough consensus that if an OAuth Provider 
follows rfc6749 verbatim will end up having an open redirector.
My next question would be now, is there anything we can do to raise some 
awareness about this issue?

regards

antonio


On Sep 4, 2014, at 3:15 PM, Hans Zandbelt  wrote:

I am convinced about the issue in the use case Antonio provided but I hope not to close 
the door on returning errors to known and trusted clients. Not sure anymore if that's 
possible though because the distinction can't be "registered"...

Hans.


On 9/4/14, 3:01 PM, Antonio Sanso wrote:
hi Bill

On Sep 4, 2014, at 2:52 PM, Bill Burke  wrote:

FWIW, Antonio convinced me and I'm going to change this in our IDM project.  
Thanks Antonio.  What convinced me was that the user is probably expecting a 
login screen.  Since there is this expectation, it might make it a little 
easier for the attacker to convince the user that a spoofed login screen is 
real.  I know this issue can only happen with unrestricted registration, but, 
IMO, this proposed change doesn't really have much of an effect on usability 
and is even backward compatible with the current RFC.

Wouldn't it better though to never do a redirect on an invalid request and just 
display an error page?


thanks for sharing your thoughts :). Display an error 400 is what Google does :)

regards

antonio




On 9/4/2014 3:50 AM, Antonio Sanso wrote:
Hi Hans,

I really fail to see how this can be addressed at registration time for cases 
where registration is unrestricted (namely all the big Providers)

regards

antonio


On Sep 4, 2014, at 9:47 AM, Hans Zandbelt  wrote:

Classifying like this must also mean that consent should not be stored until 
the client is considered (admin) trusted, and admin policy would interfere with 
user policy.

IMHO the security consideration would apply only to dynamically registered 
clients where registration is unrestricted; any other form would involve some 
form of admin/user approval at registration time, overcoming the concern at 
authorization time: there's no auto-redirect flow possible for unknown clients.

Hans.


On 9/4/14, 9:04 AM, Richer, Justin P. wrote:
I think this advice isn't a bad idea, though it's of course up to the AS
what an "untrusted" client really is. In practice, this is something
that was registered by a non-sysadmin type person, either a dynamically
registered client or something available through self-service
registration of some type. It's also reasonable that a client, even
dynamically registered, would be considered "trusted" if enough time has
passed and enough users have used it without things blowing up.

-- Justin

On Sep 4, 2014, at 1:26 AM, Antonio Sanso mailto:asa...@adobe.com>> wrote:


hi again *,

after thinking a bit further IMHO an alternative for the untrusted
clients can also be to always present the consent screen (at least
once) before any redirect.
Namely all providers I have seen show the consent screen if all the
request parameters are correct and if the user accepts the redirect
happens.
If one of the parameter  (with the exclusion of the client id and
redirect uri that are handled differently as for spec) is wrong though
the redirect happens without the consent screen being shown..

WDYT?

regards

antonio

On Sep 3, 2014, at 7:54 PM, Antonio Sanso mailto:asa...@adobe.com>> wrote:


Well,
I do not know if this is only dynamic registration...
let’s talk about real use cases, namely e.g. Google , Facebook ,
etc.. is that dynamic client registration? I do not know… :)

Said that what the other guys think?  :)
Would this deserve some “spec adjustment” ? I mean there is a reason
if Google is by choice “violating” the spec right? (I assume to avoid
open redirect…)
But other implementers do follow the spec hence they have this open
redirector… and this is not nice IMHO...


On Sep 3, 2014, at 7:40 PM, Hans Zandbelt mailto:hzandb...@pingidentity.com>> wrote:


On 9/3/14, 7:14 PM, Antonio Sanso wrote:

On Sep 3, 2014, at 7:10 PM, Hans Zandbelt
mailto:hzandb...@pingidentity.com>> wrote:


Is your concern clients that were registered using dynamic client
registration?


yes


I think your issue is then with the trust model of dynamic client
registration; that is left out of scope of the dynreg spec (and the
concept is not even part of the core spec), but unless you want
everything to be open (which typically would not be the case), then
it would involve approval somewhere in the process before the client
is registered. Without dynamic client registration that approval is
admin based or resource owner based, depending on use case.


Otherwise the positive case is returning a response to a valid URL
that belongs to a client that was registered explicitly by the
resource owner


well AFAIK the resource owner doesn’t register clients…


roles can collapse in use cases especially

Re: [OAUTH-WG] open redirect in rfc6749

[Bill Burke]

ecified below in the positive case (namely when the correct
scope
is provided) the resource owner MUST approve the app via the consent
screen (at least once).




Hans.

On 9/3/14, 6:46 PM, Antonio Sanso wrote:

hi John,
On Sep 3, 2014, at 6:14 PM, John Bradley mailto:ve7...@ve7jtb.com>
<mailto:ve7...@ve7jtb.com>
<mailto:ve7...@ve7jtb.com>> wrote:


In the example the redirect_uri is vlid for the attacker.

The issue is that the AS may be allowing client registrations with
arbitrary redirect_uri.

In the spec it is unspecified how a AS validates that a client
controls the redirect_uri it is registering.

I think that if anything it may be the registration step that
needs
the security consideration.


(this is the first time :p) but I do disagree with you. It would be
pretty unpractical to block this at registration time….
IMHO the best approach is the one taken from Google, namely
returning
400 with the cause of the error..

*400.* That’s an error.

*Error: invalid_scope*

Some requested scopes were invalid. {invalid=[l]}

said that I hope you all agree this is an issue in the spec so
far….

regards

antonio



John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke mailto:bbu...@redhat.com>
<mailto:bbu...@redhat.com>
<mailto:bbu...@redhat.com>> wrote:


I don't understand.  The redirect uri has to be valid in
order for a
redirect to happen.  The spec explicitly states this.

On 9/3/2014 11:43 AM, Antonio Sanso wrote:

hi *,

IMHO providers that strictly follow rfc6749 are vulnerable
to open
redirect.
Let me explain, reading [0]

If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or
invalid,
the authorization server SHOULD inform the resource owner of the
error and MUST NOT automatically redirect the user-agent to the
invalid redirection URI.

If the resource owner denies the access request or if the
request
fails for reasons other than a missing or invalid
redirection URI,
the authorization server informs the client by adding the
following
parameters to the query component of the redirection URI
using the
"application/x-www-form-urlencoded" format, perAppendix B
<https://tools.ietf.org/html/rfc6749#appendix-B>:

Now let’s assume this.
I am registering a new client to thevictim.com
<http://thevictim.com/>
<http://victim.com/><http://victim.com <http://victim.com/>
<http://victim.com/>>
<http://victim.com <http://victim.com/> <http://victim.com/>>
provider.
I register redirect uriattacker.com <http://uriattacker.com/>
<http://attacker.com/><http://attacker.com
<http://attacker.com/> <http://attacker.com/>>
<http://attacker.com <http://attacker.com/>
<http://attacker.com/>>.

According to [0] if I pass e.g. the wrong scope I am redirected
back to
attacker.com <http://attacker.com/>
<http://attacker.com/><http://attacker.com
<http://attacker.com/>
<http://attacker.com/>> <http://attacker.com
<http://attacker.com/> <http://attacker.com/>>.
Namely I prepare a url that is in this form:

http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com

and this is works as an open redirector.
Of course in the positive case if all the parameters are
fine this
doesn’t apply since the resource owner MUST approve the app
via the
consent screen (at least once).

A solution would be to return error 400 rather than redirect
to the
redirect URI (as some provider e.g. Google do)

WDYT?

regards

antonio

[0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1


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



--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com <http://bill.burkecentral.com/>

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


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




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



--
Hans Zandbelt  | Sr. Technical Architect
hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com>
<mailto:hzandb...@pingidentity.com>| Ping
Identity




--
Hans Zandbelt  | Sr. Technical Architect
hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com> |
Ping Identity




--
Hans Zandbe

Re: [OAUTH-WG] open redirect in rfc6749

[Bill Burke]

I don't understand.  The redirect uri has to be valid in order for a 
redirect to happen.  The spec explicitly states this.


On 9/3/2014 11:43 AM, Antonio Sanso wrote:

hi *,

IMHO providers that strictly follow rfc6749 are vulnerable to open redirect.
Let me explain, reading [0]

If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or invalid,
the authorization server SHOULD inform the resource owner of the
error and MUST NOT automatically redirect the user-agent to the
invalid redirection URI.

If the resource owner denies the access request or if the request
fails for reasons other than a missing or invalid redirection URI,
the authorization server informs the client by adding the following
parameters to the query component of the redirection URI using the
"application/x-www-form-urlencoded" format, perAppendix B  
<https://tools.ietf.org/html/rfc6749#appendix-B>:

Now let’s assume this.
I am registering a new client to the victim.com <http://victim.com>
provider.
I register redirect uri attacker.com <http://attacker.com>.

According to [0] if I pass e.g. the wrong scope I am redirected back to
attacker.com <http://attacker.com>.
Namely I prepare a url that is in this form:

http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com

and this is works as an open redirector.
Of course in the positive case if all the parameters are fine this
doesn’t apply since the resource owner MUST approve the app via the
consent screen (at least once).

A solution would be to return error 400 rather than redirect to the
redirect URI (as some provider e.g. Google do)

WDYT?

regards

antonio

[0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1


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



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

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

[Bill Burke]

On 7/24/2014 10:30 AM, Phil Hunt wrote:

Horseshit.



Horseshit to your horseshit.


Ian failed to mention that we’re responding to bad use of 6749 by
assuming receipt of access token == authentication.

The OAuth WG is not creating a new feature and we are not re-inventing
here. If anyone is, one could argue that would be OpenID —> at least in
the minds of the web developers. They don’t get why they have to use
OpenID at all.  Doesn’t OAuth already do this???



Maybe from your perspective.  From my perspective in the Java community 
at least, security for REST services is a cluster fuck.  Developers in 
the Java community are looking for answers.  For most of them, security 
is an afterthought done at the last minute.  They think OAuth will solve 
their RESTful security issues only to find that OAuth is just a 
framework not a protocol and delegates many difficult issues to 
underlying implementations.



The working group is responding to an issue that the market has ALREADY
chosen to do all by itself without the presence of any additional
specification like A4C or for that matter OpenID.

The market is doing this because_ they are under the false assumption
that OAuth is doing authentication_ and that receipt of the access token
IS authentication. It is unbelievable how many developers think OAuth
stands for Open Authentication.  The specifications are clear. Yet, the
problem persists.

If a developer already thinks they have a solution that is good enough,
why would they go to another standards organization? They aren’t even
looking for an OpenID. They think they already have THE solution!  Which
is precisely why OpenID can’t address the issue by itself!  OpenID as an
authenticator *is* re-invenention.  Yes, OpenID as an IDP provider
standard is its own innovation (re-inventing SAML and many many other
protocols of the past), but within the realm of OAuth, yes it is
innovation in my opinion..



Ridiculous statements.  How does anything above justify the existence of 
A4C.  If developers already have their solutions, why would they give a 
shit about A4C?



But keep in mind that these developers do NOT want an IDP architecture.



Says who?  You?  And what does an IDP architecture have to do with Open 
ID Connect or its use with OIDC?  You can still use a vanilla OAuth2 
client library with an IDP that implements Open ID Connect.



My point in producing the original draft was to show how simple the
correction could be — a few pages of clarifying text.

Since OpenID has been proposed as the simple solution, let me point out
why it is not for these developers: it is a specification that
incredibly complicates OAuth:

  * OpenID adds 6 response types to OAuth’s 2
  * OpenID adds 6 errors to OAuth’s 4
  * OpenID doubles the number of parameters
  * OpenID’s core specification is approximately NINETY THREE pages to
6749’s 76 pages



Like many have said over and over, A4C is already covered by OpenID. 
The subset of A4C is already legal under OpenID.



Besides, you actually think web developers care about reading some IETF 
specification?  From my 20+ years of developing middleware, developers 
do not read specifications!  They read the documentation and examples of 
the frameworks that implement these specifications.




I’m not at all saying that OpenID is bad. If you want an IDP, its fine.
  But if all a client wants is authentication, they think why can’t I
just use RFC6749?



Yup.  Like I said before.  If the IDP implements OpenID Connect, there 
is nothing stopping a client just using vanilla OAuth.



The people in the CIS audience were not aware of the facts, so of
course, they cheered against what appears to be a fork. That’s after all
how it was presented. In fact, Ian’s presentation sounds horribly
trivial and insensitive in its handling of this case.

The point is, NOT responding to this issue does not mean it goes away.
It gets worse. The market is already choosing to use OAuth for
authentication.


And OpenID Connect is OAUTH!


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

Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

[Bill Burke]

On 6/13/2014 7:15 PM, Phil Hunt wrote:


Would it be better if we thought about this as the authentication “bug”?



How can there be an authentication "bug" when OIDC has addressed it 
backed by multiple implementations by different parties?  Why don't you 
see if OIDC addresses the minor optimizations you are proposing in a4c 
before creating competing specifications which will only confuse and 
fragment the community?



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

Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

[Bill Burke]

On 6/13/2014 12:24 PM, Prateek Mishra wrote:

Excellent, now you have put your finger on the precise issue with OIDC -
lots of optional extensions and shiny trinkets and lack of a clear
definition of a core subset
for servers.



OIDC is a very clear specification.  Your phrase "shiny trinkets" hints 
that there are a lot of silly features in OIDC.  I disagree with your 
assessment.  I just see features that I want to implement and are on our 
roadmap.  At the same time, I'm relieved that I can call myself an OIDC 
compliant implementation and put off implementing these features for a 
later date.


Also, you make it sound like OIDC is this big bloated specification.  I 
completely disagree with your assessment.  Personally I see OIDC as a 
specification driven by real-world requirements and experience.




I realize its exciting for consultants, software and toolkit vendors to
have that sort of optionality, but in practice, its NOT A GOOD THING in
a protocol.



I disagree.  If OIDC core was instead broken up into a set of smaller 
optional specifications, you would run the risk of having zero 
interoperability.  Maybe that is your end-goal, but it certainly isn't 
mine.  Most of the language around optional features states that "if you 
don't implement this, your implementation needs to handle it 
gracefully".  All *GOOD* things for a protocol.


But, IMO, there is no difference in having a complete, robust 
specification like OIDC that has a lot of optional parts from re-hashing 
OIDC at the IETF with a lot of optional specifications.  Other than 
causing confusion in the community, of course.


Let me further say that my experience as an OAuth 2.0 implementor was 
difficult as it was hard to put a finger on what exact OAuth 2 
extensions people were gravitating towards.  OIDC, for me at least, gave 
a much more complete direction for my project.



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

Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

[Bill Burke]

On 6/13/2014 11:46 AM, Prateek Mishra wrote:

Thanks, Bill - I certainly appreciate the comment from an implementor
who wasnt involved in the OIDC protocol design.

My understanding of the discussion around a4c is one of a minimalist
extension to OAuth, not a full-featured one like OIDC.
One concern I have heard expressed is that OIDC is so large and full
featured that most people just implement some
subset of their own choice. I believe this is the case with all the
large consumer web sites.

I would welcome the publication of a minimalist draft from OIDC to the
OAuth IETF. We have spent a lot of time lobbying for
this outcome! There is no question in my mind that the review within
IETF would be more comprehensive and expose the work
to a larger community.



I don't think a minimalist draft of OIDC is needed as many of the 
extensions are optional.   Our implementation was already Oauth2/JWT 
based and it was really easy to meet the minimal requirements of OIDC core.


To create competing standards at IETF just because OIDC is not part of 
IETF, IMO, is a disservice to the community.



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

Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

[Bill Burke]

On 6/12/2014 4:18 PM, Phil Hunt wrote:



Phil


On Jun 12, 2014, at 12:50, Bill Burke  wrote:




On 6/12/2014 12:49 PM, Prateek Mishra wrote:
The OpenID Connect 2.0 COre specification alone is 86 pages. It has
received review from maybe a dozen engineers within the OpenID community.


The OpenID Connect spec is 86 pages because it pretty much rehashes the OAuth2 
spec walking through each flow and how Open ID Connect expands on that flow.  
A4c looks like a subset of this work minus some additional claims and, IMO, is 
incomplete compared to OIDC.

In what regards?

Much of oidc is out of scope for this requirement.



What is in a4c that isn't already in OIDC?


It is a bit like saying an 18 wheeler is suitable for driving the kids to 
school. :-)


I don't think this is true.  Most oidc oauth extensions are optional 
with the sole requirement that providers don't barf if you send them.


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

Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

[Bill Burke]

On 6/13/2014 10:21 AM, Anil Saldhana wrote:

On 06/12/2014 12:22 PM, Phil Hunt wrote:

One of the use cases is to return only a token that is NOT an access
token and is only an authentication assertion that is not opaque to
the client.

A key concern is clients do not always want to ask users for consent
to access their profiles or any other resource.  They just want
authentication.

How many times do we see things like login with Yahoo, Twitter,
Facebook and they apparently want access to too much information?
I’ve got lots of web site developers who don’t want that because it
looses registrations as a significant percentage of users always
refuse.  These developers  just want an authn ctx and the easy-sign-on
benefits.

If the developers want just the authentication context and not the
entire details about the user from providers such as Facebook, can we
just not ask with an appropriate scope for the provider? Something like
scope=username or scope=useremail. When the provider gives the data,
then it is understood that there was authentication and some user consent.


OpenID Connect already has this defined:

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

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

Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

[Bill Burke]

On 6/12/2014 12:49 PM, Prateek Mishra wrote:

The OpenID Connect 2.0 COre specification alone is 86 pages. It has
received review from maybe a dozen engineers within the OpenID community.



The OpenID Connect spec is 86 pages because it pretty much rehashes the 
OAuth2 spec walking through each flow and how Open ID Connect expands on 
that flow.  A4c looks like a subset of this work minus some additional 
claims and, IMO, is incomplete compared to OIDC.


FWIW, add 5 Red Hat engineers to the "dozen" of reviewers.  We 
originally were creating our own oauth2 extension using JWT, but found 
that any feature we wanted to define already existed in OpenID Connect. 
 These guys have done great work.   Aren't many of you here authors of 
this spec and/or the same companies?!?  I think your energies are better 
focused on lobbying OIDC to join the IETF and this WG.



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

Re: [OAUTH-WG] Client authentication and assertion grants

[Bill Burke]

On 5/20/2014 10:04 AM, Sergey Beryozkin wrote:

Hi,

Thanks for the clarification,
On 20/05/14 14:03, Brian Campbell wrote:

Yes Sergey, it's to allow for support of unregistered clients. Typically
such clients will have some relationship established with a security
token service (STS) where they can obtain assertion grants and the AS
trusts the STS to issue such assertions. In that kind of scenario, the
identity of the client can be considered unimportant - what's important
is that the AS trusts the STS and in turn the STS trusted the client
enough to issues it a suitable assertion.


What confuses me still is this: given a grant (whatever grant it is) AS
issues a token which is associated with a given client somehow.

When a registered client uses JWT or SAML assertion to authenticate it
is all clear (I can imagine the client logs on to STS, gets the
assertion and authenticates with it to AS).

Now if we have an unregistered client using an assertion grant, how do
we associate a token with this unregistered client, the text seems to
imply that the assertion grant does not identify this unregistered
client either, so it is not clear how this client can use the token
afterwards, even though AS can validate with STS/etc that the grant is
valid.

Is the idea that the registration happens after the unregistered client
has exchanged an assertion grant for a token ?

Sorry, I know I'm missing something  obvious here...



The unregistered client could, out-of-band, get its own token with the 
appropriate claims.  The unregistered client would use this token as a 
credential when asking for an access token.


I think what this setup allows you to do is to have a federated set of 
STS services.  Where one STS deals with providing access tokens for 
applications and another deals with providing access tokens for clients 
to access application STS services :)  Instead of just one auth server 
having to know about everything, you can delegate things to different 
servers.


Am I on the right track?

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

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)

[Bill Burke]

On 4/25/2014 4:12 PM, Brian Campbell wrote:


IHMO getting everyone to agree on the specific claims etc. needed for a
standardized JWT access token is a bit of a rat's nest, which is why
there's not been much progress in that area.



I guess any IANA registry submissions for new JWT claims is premature 
until an RFC is out for JWT?  Or are people writing drafts for their own 
personal claims?


Thanks.

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

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)

[Bill Burke]

Thank you.  Thats what I thought.  Is it just assumed JWT would/might be 
used an access token format for Bearer token auth?  Or is there another 
draft somewhere for that?  Is anybody out there using JWS + JWT as a 
access token format?


On 4/25/2014 2:59 PM, Brian Campbell wrote:

draft-ietf-oauth-jwt-bearer is only about interactions (client
authentication and JWT as an authorization grant) with the token
endpoint and doesn't define JWT style access tokens.


On Fri, Apr 25, 2014 at 12:51 PM, Bill Burke mailto:bbu...@redhat.com>> wrote:

Red Hat Keycloak [1] only supports basic auth for client
authentication as suggested in the OAuth 2 spec.  But our access
tokens are JWS signed JWTs.

Does draft-ietf-oauth-jwt-bearer relate to OAuth Bearer token auth
[2]?  Or is there another document I should be following?  I'd like
to see what other claims are being discussed related to JWT-based
access tokens and may have some additional access token claims we've
been experimenting with others might be interested in.

Also, I'm not sure yet if we'll implement
draft-ietf-oauth-jwt-bearer to authenticate clients.  A lot of our
initial users are more interested in public clients and/or the
implicit flow as they are writing a lot of pure javascript apps
served up by simple static web servers.

[1] http://keycloak.org
[2] http://tools.ietf.org/html/__rfc6750
<http://tools.ietf.org/html/rfc6750>



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

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

[Bill Burke]

d.

However, this document depends on the completion of the abstract OAuth
assertion framework and on the JWT specification.
There are the following dependencies:

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

The publication of this document does not change the status of other
RFCs.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The document registers two sub-namespaces to the urn:ietf:params:oauth
URN established with RFC 6755.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

The document only adds entries to existing registries and does not
define any new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There are only snippets of message exchanges and JWT assertion
structures, which are based on JSON, used in the examples. There is no
pseudo code contained in the document that requires validation.



___
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


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



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

Re: [OAUTH-WG] CORS and public vs. confidential clients

[Bill Burke]

The thread model doc was really great, but I still couldn't find 
anything concrete on what guarantees you lose if you use a public client 
vs. a confidential one.  Honestly, I'm just trying to have the right 
info to guide users on what auth flow to use and the pros/cons.


On 3/27/2014 7:59 PM, Prateek Mishra wrote:

Bill - as you are referencing CORS in your message, I assume you are
discussing a Javascript-only (browser) client. I believe the implicit flow
was designed for this case and this flow never involves a confidential
client.

Yes, it is a Javascript (browser) client.  Implicit flow doesn't allow 
for a refresh token.  Our browser javascript code uses CORS also when 
participating in the access code grant flow.


Our access codes are digitally signed, and unique.  They can only be 
turned into an access token once.  They are associated privately with a 
redirect URI, state, and client_id.  And they have a timeout.  We do 
validation/verification at each part of the flow to make sure the 
redirectURI, state, and/or client_id is valid.  I just want to know what 
to tell users what security implications there are if they use a public 
client in this scenario.



Confidential clients may be used with the other flows (code,
resource,..) that are capable of making a TLS call to a Token Endpoint.



BTW, Is there a better list for these types of questions?  Didn't have a 
lot of luck on the Google Group for OAuth.


--
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-WG] CORS and public vs. confidential clients

[Bill Burke]

I'm still trying to wrap my head around the differences between public 
and confidential clients.  In our IDP impl, we check redirect uris and 
associate a lot of private metadata to the access code to ensure there 
is no client_id swapping.  My understanding was that confidential 
clients made sure that only an authenticated client could obtain an 
access token.


What if you throw CORS in the mix where your browser needs the access 
token (and the ability to refresh it) to make cross-domain requests? 
Doesn't this remove a large benefit of confidential clients?


Anybody know a good document that describes the difference and pros/cons 
of public vs. confidential clients beyond the actual OAUTH spec itself?


Thanks

--
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-WG] can public clients be as safe in Auth Code Grants?

[Bill Burke]

Section 3.2.1 talks about the need for and benefits of confidential 
clients.  For Auth Code Grants, can't public clients be as safe as 
confidential clients if:


* HTTPS is being used for all communication
* Valid redirect_uri patterns are registered at the Auth Server for the 
public clients
* Auth server validates the client's redirect_uri when processing a 
Authorization Request.  The browser would ensure you are redirecting to 
a valid domain.
* "state" parameter is validated by the client from the Authorization 
Response.
* Client sends its "client_id" and "redirect_uri" when making a Access 
Token Request
* Auth server revalidates "client_id", "redirect_uri" to data used to 
create the Auth Code.



Nobody could fake being the public client because an auth code could 
only be sent to the registered redirect URLs of the public client.


As for the statement that it might be easier to change client 
credentials than to revoke refresh tokens, couldn't his also be 
mitigated if the Auth Server supported setting a revocation policy for 
the client?


Thanks in advance.

Bill

p.s. FYI, maybe I did something wrong, but I couldn't seem to get 
anything posted on the Google Group for OAuth.  Hope its ok to post 
these kinds of questions here.


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