Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

My experience: When building modern applications, we use OIDC and OAuth together for authentication, session management and API access. Only the combination makes sense (to me) here. Hence it also makes sense (for me) to share claims types going forward. IdentityServer is a framework that is typi

Re: [OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00

Multiple concepts often get tacked onto a particular term, which both aids and hinders communication. From RFC 6749, a public client is defined as: "Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resour

[OAUTH-WG] DPoP blog post

FYI, I posted about the new DPoP draft at http://self-issued.info/?p=1967 and as @selfissued, asking people to have a look and provide feedback. -- Mike ___ OAuth

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

I will argue that in a way such deployments are already broken e.g. in the typical use case of onboarding client accounts in the same directory/OU/namespace as user accounts and we don't need to cater for that.. Hans. On Wed, Apr 3, 2019 at 10:48 PM George Fletcher wrote: > I agree that this wi

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

I agree that this will break a lot of existing flows... especially those using any form of the client_credentials flow. In that sense I'm not completely on board yet :) On 3/26/19 12:56 PM, Hans Zandbelt wrote: great summary! this will hurt quite a few existing m2m deployments but I do like th

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Thanks guys for the comment, sorry for the delay in addressing them. I am not married to the claim types used in here, so if you think that reusing the ones in the id_token can cause confusion we should expand on the specific ways in which you think might go south. However I think it's important th

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

+1 to David's question here. I'd like to see justifying use cases (beyond just the fact that some people are already doing it) for auth_time, acr, and amr to be available in OAuth JWT access tokens. Those claims are defined for, and in the context of, an ID Token and I fear that codifying their use

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

Perfect! Thank you! A couple comments on version 01... POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded;charset=UTF-8 DPoP-Binding: eyJhbGciOiJSU0ExXzUi ... grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

This is fixed in -01: https://tools.ietf.org/html/draft-fett-oauth-dpop-01 -Daniel Am 03.04.19 um 17:28 schrieb George Fletcher: > A quick question regarding... > >o "http_uri": The HTTP URI used for the request, without query and > fragment parts (REQUIRED). > > Is 'without' supposed

Re: [OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00

From a security perspective, I think that using a UUID (or session cookie) which allows the SPA to retrieve the access_token is effectively the same as the confidential client directly returning the AT to the browser. Basically, it's the different between whether the browser has a copy of the a

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

A quick question regarding... o "http_uri": The HTTP URI used for the request, without query and fragment parts (REQUIRED). Is 'without' supposed to be 'with' ? The example shows the http_uri *with* the query parameters :) On 3/28/19 6:17 AM, Daniel Fett wrote: Hi all, I publish

Re: [OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00

Hi, I've seem some implementations where the token is not directly delivered to the browser by the backend, but some temporary UUID that later the SPA can exchange for an access token. Do you think this is a good approach to the recommendation you are discussing? In addition to that, could you c