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

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

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

s 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

sword 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

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

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

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

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 ses

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

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

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

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

d 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

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

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

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

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

ent. 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 additiona

Re: [OAUTH-WG] Token Exchange Implementations

> 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

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

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

t; >> 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. >> &g

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

th 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

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

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

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

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

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

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

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 a

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

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

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

57SbK10&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=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY0

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

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

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

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

[OAUTH-WG] oauth with command line clients

dy 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

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 min

Re: [OAUTH-WG] redircet_uri matching algorithm

ult 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

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

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

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

t; 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?

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

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

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

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

onseModes>. 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@ie

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

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

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

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

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

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

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

Re: [OAUTH-WG] open redirect in rfc6749

e 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

Re: [OAUTH-WG] open redirect in rfc6749

e* 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:

Re: [OAUTH-WG] open redirect in rfc6749

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

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

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 ht

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

esses 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

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

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

ready 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.burkecentra

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

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

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

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

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

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

pplications 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

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

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

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

-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

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

_ 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

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

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

now 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

[OAUTH-WG] can public clients be as safe in Auth Code Grants?

, 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