Re: [OAUTH-WG] OAuth: The frustrating lack of good libraries

[Sascha Preibisch]

Hello Daniel!

Some time ago I started an open source project: Loginbuddy.
Loginbuddy is a tool that mainly supports OpenID Connect based logins.

It can be deployed as a standalone service or be used as a side-car next to
other docker containers in the same network.

Although it is not necessarily a library, it may be worth looking into it.
I could imagine that Loginbuddy would also be a good starting point for
extensions that serve more flows and more general features of OAuth/ OpenID
Connect. With more contributors I see a chance for Loginbuddy to be more
widely used and help address your concerns.

Please have a look here:
https://loginbuddy.net

I just updated the web site. Or visit the GitHub project:
https://github.com/SaschaZeGerman/loginbuddy

In any case, that is my current contribution to the developer community.

Thanks,
Sascha

On Tue, Mar 1, 2022 at 9:18 AM Daniel Fett  wrote:

> *Hi all,*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> * While helping clients to onboard into the yes ecosystem, in my
> consulting work, and in discussions with developers implementing OAuth 2.0,
> one topic comes up increasingly often: The (somewhat frustrating) lack of
> good, modern, and universal OAuth libraries.  Many of the libraries out
> there have one or more of the following drawbacks:  * They are not
> maintained any longer  * They are not well documented (e.g., it is often
> unclear which specifications are supported)  * They support only a subset
> of the OAuth 2.0 specification  * They work only with selected providers
> (e.g., Google, Facebook, etc.)  * It is unclear whether they follow recent
> security recommendations  * They do not support modern features, such as
> PKCE, AS Metadata, MTLS, etc. Exceptions exist, of course, like Filip's
> Node.js implementation and the nimbus library for Java. But apart from
> those rare cases, when a developer asks me what library to use, my answer
> is often: "I don't think there's a good one in your language". It is a
> telltale sign that many providers of OAuth protected APIs also provide a
> custom OAuth implementation in their SDKs, which they then often have to
> maintain for a number of languages. This creates unnecessary costs and
> friction, e.g., when introducing new security features. At the same time,
> practically every language/framework comes with a TLS stack and making
> HTTPS requests is often just a few lines of code. Why aren't we there yet
> with OAuth? I'm well aware that OAuth 2.0 is a framework, not a single
> protocol like TLS, but the mentioned libraries show that this does not
> preclude a comprehensive library support. If I had to speculate about the
> reasons for this mess, I'd say that there are three:  * The core of OAuth
> is easy to implement. The need to create or use a library might not be
> obvious to developers. Of course, if you want a proper implementation with
> correct error handling, observing all the security recommendations, etc.,
> the effort is huge. But just getting OAuth to work for one specific use
> case is relatively easy.  * OAuth is traditionally hard to configure:
> authorization and token endpoint URLs, client id and secret, supported
> scopes (and claims for OIDC), supported response types and modes, and
> required security features are just some of the things a developer has to
> figure out - often from the API's documentation - to get everything up and
> running. Even though configuration is not the same as implementation, I
> imagine that this complexity can lead to the perception that there are
> barely any commonalities between different OAuth flows. There might be no
> value, after all, in an OAuth library, if I have to provide so many details
> myself.  * With many extensions and specifications to choose from, it can
> be hard to select a reasonable subset to support.  What can we do about
> this? I'm not sure, but I have a few ideas.  * Of course, one step would be
> to increase visibility and documentation for existing implementations:
> Beyond listing libraries (like the list on oauth.net ),
> it would be great to have a place to go to to find libraries based on their
> feature support. I'm sure there are more good libraries out there.  * The
> OpenID Foundation has a great set of conformance tests for OIDC, FAPI and
> other stuff. Creating conformance tests for OAuth would be harder, given
> that the framework leaves many options for implementers to choose from. I’m
> not sure if running a conformance programme would be in the scope of IETF,
> but it can be worthwhile to think about if we could support such an
> endeavor.  * The single most important thing to do would, in my opinion, be
> to set a goal: Tell library developers and language maintainers what can be
> expected from a good, modern, and universal OAuth library. Such a
> recommendation would shine a light on the most important extensions for
> OAuth like PKCE and might even be a prerequisite for conformance tests. It
> may turn out 

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

[Sascha Preibisch]

Ok, if the goal is to avoid unnecessary requirements I am suggesting to
point out why MUST was changed to SHOULD. Otherwise developers will start
to mix and match OAuth 2.0 and OAuth 2.1 requirements as they see them fit
their needs.
In regards to encrypted values in PKCE, Aaron, I can also not confirm that
as the general implementation.

On Wed, 13 Oct 2021 at 13:56, Aaron Parecki  wrote:

> The PKCE spec actually says "Typically, the "code_challenge" and
> "code_challenge_method" values are stored in encrypted form in the "code"
> itself" which I feel like might be a stretch to say that's typical, but
> this scenario was clearly thought of ahead of time. Doing that would enable
> an AS to avoid storing server-side state.
>
> On Wed, Oct 13, 2021 at 1:50 PM Sascha Preibisch <
> saschapreibi...@gmail.com> wrote:
>
>> If the challenge is based on distributed authorization server
>> configurations, how would they handle PKCE? I imagine that managing the
>> state for PKCE is not less challenging than managing authorization codes on
>> the server side, preventing reuse of them.
>> With that in mind I am not sure if I follow the given argument. I would
>> prefer to keep MUST as it is today.
>>
>>
>> On Wed, 13 Oct 2021 at 13:37, Aaron Parecki  wrote:
>>
>>> HTTPS, because if that's broken then the rest of OAuth falls apart too.
>>>
>>> On Wed, Oct 13, 2021 at 1:36 PM Warren Parad  wrote:
>>>
>>>> I feel like I'm missing something, what stops just plain old network
>>>> sniffing and replying the whole encrypted payload to the AS and getting
>>>> back a valid token?
>>>>
>>>> Warren Parad
>>>>
>>>> Founder, CTO
>>>> Secure your user data with IAM authorization as a service. Implement
>>>> Authress <https://authress.io/>.
>>>>
>>>>
>>>> On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki 
>>>> wrote:
>>>>
>>>>> Aside from the "plain" method, the PKCE code verifier never leaves the
>>>>> client until it's sent along with the authorization code in the POST
>>>>> request to the token endpoint. The only place it can leak at that point is
>>>>> if the authorization server itself leaks it. If you have things leaking
>>>>> from the authorization server log, you likely have much bigger problems
>>>>> than authorization code replays.
>>>>>
>>>>> Keep in mind that even with the proposed change to drop the
>>>>> requirement of authorization codes being one time use, authorization
>>>>> servers are free to enforce this still if they want. Authorization code
>>>>> lifetimes are still expected to be short lived as well.
>>>>>
>>>>> Aaron
>>>>>
>>>>>
>>>>> On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman <
>>>>> pieter.kassel...@microsoft.com> wrote:
>>>>>
>>>>>> Aaron, I was curious what prevents an attacker from presenting an
>>>>>> Authorization Code and a PKCE Code Verifier for a second time if the one
>>>>>> time use requirement is removed. Is there another countermeasure in  PKCE
>>>>>> that would prevent it? For example, an attacker may obtain the
>>>>>> Authorization Code and the Code Verifier from a log and replay it.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>>
>>>>>>
>>>>>> Pieter
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* OAuth  *On Behalf Of *Aaron Parecki
>>>>>> *Sent:* Wednesday 13 October 2021 18:40
>>>>>> *To:* Warren Parad 
>>>>>> *Cc:* Mike Jones ;
>>>>>> oauth@ietf.org
>>>>>> *Subject:* [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and
>>>>>> OAuth 2.1
>>>>>>
>>>>>>
>>>>>>
>>>>>> Warren, I didn't see you on the interim call, so you might be missing
>>>>>> some context.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The issue that was discussed is that using PKCE already provides all
>>>>>> the security benefit that is gained by enforcing single-use authorization
>>>>>> codes. Therefore, requiring that they

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

[Sascha Preibisch]

If the challenge is based on distributed authorization server
configurations, how would they handle PKCE? I imagine that managing the
state for PKCE is not less challenging than managing authorization codes on
the server side, preventing reuse of them.
With that in mind I am not sure if I follow the given argument. I would
prefer to keep MUST as it is today.


On Wed, 13 Oct 2021 at 13:37, Aaron Parecki  wrote:

> HTTPS, because if that's broken then the rest of OAuth falls apart too.
>
> On Wed, Oct 13, 2021 at 1:36 PM Warren Parad  wrote:
>
>> I feel like I'm missing something, what stops just plain old network
>> sniffing and replying the whole encrypted payload to the AS and getting
>> back a valid token?
>>
>> Warren Parad
>>
>> Founder, CTO
>> Secure your user data with IAM authorization as a service. Implement
>> Authress .
>>
>>
>> On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki  wrote:
>>
>>> Aside from the "plain" method, the PKCE code verifier never leaves the
>>> client until it's sent along with the authorization code in the POST
>>> request to the token endpoint. The only place it can leak at that point is
>>> if the authorization server itself leaks it. If you have things leaking
>>> from the authorization server log, you likely have much bigger problems
>>> than authorization code replays.
>>>
>>> Keep in mind that even with the proposed change to drop the requirement
>>> of authorization codes being one time use, authorization servers are free
>>> to enforce this still if they want. Authorization code lifetimes are still
>>> expected to be short lived as well.
>>>
>>> Aaron
>>>
>>>
>>> On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman <
>>> pieter.kassel...@microsoft.com> wrote:
>>>
 Aaron, I was curious what prevents an attacker from presenting an
 Authorization Code and a PKCE Code Verifier for a second time if the one
 time use requirement is removed. Is there another countermeasure in  PKCE
 that would prevent it? For example, an attacker may obtain the
 Authorization Code and the Code Verifier from a log and replay it.



 Cheers



 Pieter



 *From:* OAuth  *On Behalf Of *Aaron Parecki
 *Sent:* Wednesday 13 October 2021 18:40
 *To:* Warren Parad 
 *Cc:* Mike Jones ;
 oauth@ietf.org
 *Subject:* [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and
 OAuth 2.1



 Warren, I didn't see you on the interim call, so you might be missing
 some context.



 The issue that was discussed is that using PKCE already provides all
 the security benefit that is gained by enforcing single-use authorization
 codes. Therefore, requiring that they are single-use isn't necessary as it
 doesn't provide any additional benefit.



 If anyone can think of a possible attack by allowing authorization
 codes to be reused *even with a valid PKCE code verifier* then that would
 warrant keeping this requirement.



 ---

 Aaron Parecki





 On Wed, Oct 13, 2021 at 10:27 AM Warren Parad >>> 40rhosys...@dmarc.ietf.org> wrote:

 Isn't it better for it to be worded as we want it to be, with the
 implication being that of course it might be difficult to do that, but that
 AS devs will think long and hard about sometimes not denying the request?
 Even with MUST, some AS will still allow reuse of auth codes. Isn't that
 better than flat out saying: *sure, there's a valid reason*



 In other words, how do we think about RFCs? Do they exist to be
 followed to the letter or not at all? Or do they exist to stipulate this is
 the way, but acknowledge that not everyone will build a solution that holds
 them as law.



 Let's look at *SHOULD*

 This word, or the adjective "RECOMMENDED", mean that there may exist
 valid reasons in particular circumstances to ignore a particular item, but
 the full implications must be understood and carefully weighed before
 choosing a different course.



 I think *recommended* here is not sufficient nor are there valid
 reasons. "It's too hard" isn't really a valid reason. Isn't it better in
 this case for an AS to not be compliant with the RFC, than it is to relax
 this to SHOULD and have lots of AS thinking reusing auth codes is a viable
 solution, "because they are a special snowflake where SHOULD should apply".



 Are we setting the standard or instead attempting to sustain a number
 of "AS that are in compliance with the RFC"?



 *Warren Parad*

 Founder, CTO

 Secure your user data with IAM authorization as a service. Implement
 Authress
 

Re: [OAUTH-WG] self-issued access tokens

[Sascha Preibisch]

Yeah, Daniel,

I remember we spoke about it. I do think my version is slightly different
as there is no access_token issued by the server.

Regards,
Sascha

On Wed, 29 Sept 2021 at 08:42, Daniel Fett  wrote:

> That very much sounds like a static string as the access token plus DPoP.
>
> -Daniel
>
> Am 29.09.21 um 03:54 schrieb toshio9@toshiba.co.jp:
>
> Hi OAuth folks,
>
> I have a question. Is there (or was there) any standardizing effort for
> "self-issued access tokens"?
>
> Self-issued access tokens are mentioned in a blog post by P. Siriwardena in 
> 2014
> [*1]. It's an Access Token issued by the Client and sent to the Resource 
> Server.
> The token is basically a signed document (e.g. JWT) by the private key of the
> Client. The Resource Server verifies the token with the public key, which is
> provisioned in the RS in advance.
>
> I think self-issued access tokens are handy replacement for Client Credentials
> Grant flow in simple deployments, where it's not so necessary to separate AS 
> and
> RS. In fact, Google supports this type of authentication for some services
> [*2][*3]. I'm wondering if there are any other services supporting self-signed
> access tokens.
>
> Any comments are welcome.
>
> [*1]: 
> https://wso2.com/library/blog-post/2014/10/blog-post-self-issued-access-tokens/
> [*2]: 
> https://developers.google.com/identity/protocols/oauth2/service-account#jwt-auth
> [*3]: https://google.aip.dev/auth/4111
>
> -
> Toshio Ito
> Research and Development Center
> Toshiba Corporation
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> -- https://danielfett.de
>
> ___
> 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] self-issued access tokens

[Sascha Preibisch]

Vittorio,

I wrote an approach where a client would receive a grant by the
authorization server but issues the token itself. The post can be found
here:
https://oauth.blog/oauthblog.jsp (fancy name: Serverless Token Issuance) I
presented the idea at IIW right before I wrote the post.

I believe that it would work nicely and would avoid the need for an
authorization servers to manage access_token.

Regards,
Sascha


On Tue, 28 Sept 2021 at 23:13, Vittorio Bertocci  wrote:

> Hi Toshio,
> The scenario you describe is comparable to
> https://openid.net/specs/openid-connect-self-issued-v2-1_0.html, at least
> in terms of validation logic. Please note that most of the validation
> software in common use today expects to work with just a handful of keys,
> typically one provider and allowance for rotation, hence it might not be
> trivial to repurpose it to perform large table scans in scenarios where you
> have many clients and corresponding keys.
> Also, Prabath's blog makes a statement that, I believe, overstates what
> can be achieved with this approach: he says that this can be a replacement
> for TLS mutual authentication, but it isn't really the case as you are
> still dealing with a bearer token, which can be replayed after issuance
> hence offering less guarantees than mutual TLS.
>
>
> On Tue, Sep 28, 2021 at 6:54 PM  wrote:
>
>> Hi OAuth folks,
>>
>> I have a question. Is there (or was there) any standardizing effort for
>> "self-issued access tokens"?
>>
>> Self-issued access tokens are mentioned in a blog post by P. Siriwardena
>> in 2014
>> [*1]. It's an Access Token issued by the Client and sent to the Resource
>> Server.
>> The token is basically a signed document (e.g. JWT) by the private key of
>> the
>> Client. The Resource Server verifies the token with the public key, which
>> is
>> provisioned in the RS in advance.
>>
>> I think self-issued access tokens are handy replacement for Client
>> Credentials
>> Grant flow in simple deployments, where it's not so necessary to separate
>> AS and
>> RS. In fact, Google supports this type of authentication for some services
>> [*2][*3]. I'm wondering if there are any other services supporting
>> self-signed
>> access tokens.
>>
>> Any comments are welcome.
>>
>> [*1]:
>> https://wso2.com/library/blog-post/2014/10/blog-post-self-issued-access-tokens/
>> [*2]:
>> https://developers.google.com/identity/protocols/oauth2/service-account#jwt-auth
>> [*3]: https://google.aip.dev/auth/4111
>>
>> -
>> Toshio Ito
>> Research and Development Center
>> Toshiba Corporation
>>
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Can a client send the Authorization Request?

[Sascha Preibisch]

Yes, I understand. I just wanted to clarify how I came up with ssying POST
is an option.
Regards,
Sascha


On Tue., May 25, 2021, 22:17 A. Rothman,  wrote:

> Oh, I see what you mean... however as Justin clarified, the discussion
> here is not about GET vs POST, but rather about user agent vs client making
> the request. The former distinction doesn't really matter in this case,
> whereas in the latter distinction the client option seems to be breaking
> the spec (only the user agent should send it).
>
> Amichai
> On 5/26/21 4:15 AM, Sascha Preibisch wrote:
>
> Amichai,
>
> I know POST won't be seen often, but the /authorize endpoint may still
> accept POST as described here:
> https://tools.ietf.org/html/rfc6749#section-3.1
>
> I hope this helps,
> Sascha
>
>
> On Tue., May 25, 2021, 13:00 A. Rothman,  wrote:
>
>> Hi Sacha,
>>
>> Thanks for the links and video!
>>
>> However I don't think this is what they're doing. There's no par
>> endpoint, no JSON response (just a redirect with a Location header, that
>> instead of following, the client is supposed to pass through to the user
>> agent), etc. It seems more like a regular OAUTH2 flow, just with the
>> initial request coming out of the client instead of the user agent, without
>> any of the specifics of the par mentioned in the video.
>>
>> btw, where does RFC 6749 say the authorization request can be sent by the
>> client? In the quote I made below from 4.1, as well as e.g. 4.2.1, it seems
>> pretty explicit that it's the user agent that makes the actual HTTP request
>> (Authorization Request with all its params etc), after being redirected to
>> it from the client, no? I don't see much wiggle room there to allow for the
>> client to be sending it itself...
>>
>> Amichai
>> On 5/25/21 6:28 PM, Sascha Preibisch wrote:
>>
>> Hello Amichai!
>>
>> There could be several reasons why you see that behaviour in your web
>> browser. For example:
>>
>> - This RFC suggests sending a request to the authorization server, get a
>> session specific URL back which can be forwarded to the authorization
>> server via the browser. This is OAuth PAR (Pushed Authorization Request):
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par. I have also
>> made a video about this flow, maybe it matches what you are seeing on your
>> web server: https://www.youtube.com/watch?v=fE11HJRCL-k
>>
>> - In addition RFC 6749 also allows a client to POST to the authorization
>> endpoint
>>
>> I hope this helps,
>> Sascha
>>
>> On Tue, 25 May 2021 at 08:00, A. Rothman  wrote:
>>
>>> Hi,
>>>
>>> In RFC 6749 section 4.1, the Authorization Code Grant flow starts with:
>>>
>>> (A)  The client initiates the flow by directing the resource owner's
>>>  user-agent to the authorization endpoint.  The client includes
>>>  its client identifier, requested scope, local state, and a
>>>  redirection URI to which the authorization server will send the
>>>  user-agent back once access is granted (or denied).
>>>
>>> (B)  The authorization server authenticates the resource owner (via
>>>  the user-agent) and establishes whether the resource owner
>>>  grants or denies the client's access request.
>>>
>>>
>>>  From this, and most explanation I've seen, I understand that the client
>>> (e.g. my web server) is supposed to prepare the Authorization Request
>>> URL but instead of sending it to the Authorization Server, it redirects
>>> the user agent which is the one actually making the HTTP request. It
>>> then goes back and forth with the Authorization Server (with HTML and
>>> posting forms and whatnot), and eventually receives the Authorization
>>> Response which redirects the user agent back to the client's callback
>>> URL with the included code parameter. So as far as the Authorization
>>> Request/Response flow goes, there is no direct communications between
>>> the client and Authorization Server up to this point (before the token
>>> exchange).
>>>
>>> 1. Basically correct so far?
>>>
>>> Now, I've encountered a provider that works slightly differently (but
>>> still with the Authorization Code Grant scheme): the client (my web
>>> server) is supposed to send the Authorization Request directly to the
>>> Authorization Server, then receive some opaque URL, and redirect the
>>> user agent to there to continue the process. I suppose th

Re: [OAUTH-WG] Can a client send the Authorization Request?

[Sascha Preibisch]

Amichai,

I know POST won't be seen often, but the /authorize endpoint may still
accept POST as described here:
https://tools.ietf.org/html/rfc6749#section-3.1

I hope this helps,
Sascha


On Tue., May 25, 2021, 13:00 A. Rothman,  wrote:

> Hi Sacha,
>
> Thanks for the links and video!
>
> However I don't think this is what they're doing. There's no par endpoint,
> no JSON response (just a redirect with a Location header, that instead of
> following, the client is supposed to pass through to the user agent), etc.
> It seems more like a regular OAUTH2 flow, just with the initial request
> coming out of the client instead of the user agent, without any of the
> specifics of the par mentioned in the video.
>
> btw, where does RFC 6749 say the authorization request can be sent by the
> client? In the quote I made below from 4.1, as well as e.g. 4.2.1, it seems
> pretty explicit that it's the user agent that makes the actual HTTP request
> (Authorization Request with all its params etc), after being redirected to
> it from the client, no? I don't see much wiggle room there to allow for the
> client to be sending it itself...
>
> Amichai
> On 5/25/21 6:28 PM, Sascha Preibisch wrote:
>
> Hello Amichai!
>
> There could be several reasons why you see that behaviour in your web
> browser. For example:
>
> - This RFC suggests sending a request to the authorization server, get a
> session specific URL back which can be forwarded to the authorization
> server via the browser. This is OAuth PAR (Pushed Authorization Request):
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par. I have also
> made a video about this flow, maybe it matches what you are seeing on your
> web server: https://www.youtube.com/watch?v=fE11HJRCL-k
>
> - In addition RFC 6749 also allows a client to POST to the authorization
> endpoint
>
> I hope this helps,
> Sascha
>
> On Tue, 25 May 2021 at 08:00, A. Rothman  wrote:
>
>> Hi,
>>
>> In RFC 6749 section 4.1, the Authorization Code Grant flow starts with:
>>
>> (A)  The client initiates the flow by directing the resource owner's
>>  user-agent to the authorization endpoint.  The client includes
>>  its client identifier, requested scope, local state, and a
>>  redirection URI to which the authorization server will send the
>>  user-agent back once access is granted (or denied).
>>
>> (B)  The authorization server authenticates the resource owner (via
>>  the user-agent) and establishes whether the resource owner
>>  grants or denies the client's access request.
>>
>>
>>  From this, and most explanation I've seen, I understand that the client
>> (e.g. my web server) is supposed to prepare the Authorization Request
>> URL but instead of sending it to the Authorization Server, it redirects
>> the user agent which is the one actually making the HTTP request. It
>> then goes back and forth with the Authorization Server (with HTML and
>> posting forms and whatnot), and eventually receives the Authorization
>> Response which redirects the user agent back to the client's callback
>> URL with the included code parameter. So as far as the Authorization
>> Request/Response flow goes, there is no direct communications between
>> the client and Authorization Server up to this point (before the token
>> exchange).
>>
>> 1. Basically correct so far?
>>
>> Now, I've encountered a provider that works slightly differently (but
>> still with the Authorization Code Grant scheme): the client (my web
>> server) is supposed to send the Authorization Request directly to the
>> Authorization Server, then receive some opaque URL, and redirect the
>> user agent to there to continue the process. I suppose this URL is
>> equivalent to one from the middle of the 'back and forth' in the
>> previous scenario. The rest of the flow continues the same. So
>> basically, the initial redirect response and HTTP request are reversed -
>> instead of first redirect and then request (from user agent), there is
>> first the request (from client)  and then redirect.
>>
>> So the questions are:
>>
>> 2. Is this compliant with the RFC?
>>
>> 3. Is it any less secure? (even if not strictly compliant with the RFC's
>> flow, it may still be secure...)
>>
>> 4. If it is less secure, what are the possible vulnerabilities or
>> attacks made possible here that are mitigated in the original flow?
>>
>> 5. They claim the change is made because they insist on using MTLS on
>> all Authentication Server endpoints, including the Authorization
>> Endpoint. Does this make sense? Does it add security, or is the OAUTH2
>> flow just as secure without MTLS on the Authorization Endpoint?
>>
>> Thanks,
>>
>> Amichai
>>
>>
>>
>> ___
>> 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] Can a client send the Authorization Request?

[Sascha Preibisch]

Hello Amichai!

There could be several reasons why you see that behaviour in your web
browser. For example:

- This RFC suggests sending a request to the authorization server, get a
session specific URL back which can be forwarded to the authorization
server via the browser. This is OAuth PAR (Pushed Authorization Request):
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par. I have also
made a video about this flow, maybe it matches what you are seeing on your
web server: https://www.youtube.com/watch?v=fE11HJRCL-k

- In addition RFC 6749 also allows a client to POST to the authorization
endpoint

I hope this helps,
Sascha

On Tue, 25 May 2021 at 08:00, A. Rothman  wrote:

> Hi,
>
> In RFC 6749 section 4.1, the Authorization Code Grant flow starts with:
>
> (A)  The client initiates the flow by directing the resource owner's
>  user-agent to the authorization endpoint.  The client includes
>  its client identifier, requested scope, local state, and a
>  redirection URI to which the authorization server will send the
>  user-agent back once access is granted (or denied).
>
> (B)  The authorization server authenticates the resource owner (via
>  the user-agent) and establishes whether the resource owner
>  grants or denies the client's access request.
>
>
>  From this, and most explanation I've seen, I understand that the client
> (e.g. my web server) is supposed to prepare the Authorization Request
> URL but instead of sending it to the Authorization Server, it redirects
> the user agent which is the one actually making the HTTP request. It
> then goes back and forth with the Authorization Server (with HTML and
> posting forms and whatnot), and eventually receives the Authorization
> Response which redirects the user agent back to the client's callback
> URL with the included code parameter. So as far as the Authorization
> Request/Response flow goes, there is no direct communications between
> the client and Authorization Server up to this point (before the token
> exchange).
>
> 1. Basically correct so far?
>
> Now, I've encountered a provider that works slightly differently (but
> still with the Authorization Code Grant scheme): the client (my web
> server) is supposed to send the Authorization Request directly to the
> Authorization Server, then receive some opaque URL, and redirect the
> user agent to there to continue the process. I suppose this URL is
> equivalent to one from the middle of the 'back and forth' in the
> previous scenario. The rest of the flow continues the same. So
> basically, the initial redirect response and HTTP request are reversed -
> instead of first redirect and then request (from user agent), there is
> first the request (from client)  and then redirect.
>
> So the questions are:
>
> 2. Is this compliant with the RFC?
>
> 3. Is it any less secure? (even if not strictly compliant with the RFC's
> flow, it may still be secure...)
>
> 4. If it is less secure, what are the possible vulnerabilities or
> attacks made possible here that are mitigated in the original flow?
>
> 5. They claim the change is made because they insist on using MTLS on
> all Authentication Server endpoints, including the Authorization
> Endpoint. Does this make sense? Does it add security, or is the OAUTH2
> flow just as secure without MTLS on the Authorization Endpoint?
>
> Thanks,
>
> Amichai
>
>
>
> ___
> 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 2.0 Pushed Authorization Requests: Implementation Status

[Sascha Preibisch]

Hello Hannes!

I have implemented PAR a while ago in my open source project "Loginbuddy"
as documented here:
- documentation:
https://github.com/SaschaZeGerman/loginbuddy/wiki/Protocols-and-APIs
- endpoint: /pauthorize

I hope it hope,
Sascha

On Wed, 24 Mar 2021 at 12:54, Hannes Tschofenig 
wrote:

> Hi all,
>
>
>
> I am working on the shepherd writeup and I need information about the
> implementation status of this specification.
>
>
>
> Can you share whether you are implementing, or planning to implement this
> specification? If there is open source, please drop a link to the mailing
> list. If you implement it in your product, please let us know as well.
>
>
>
> This information helps the steering committee to judge the quality and
> maturity of the work.
>
>
>
> Ciao
>
> Hannes
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. 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

Re: [OAUTH-WG] oauth par - authorize request with client_id

[Sascha Preibisch]

Thank you, Taka!

I will check out the referenced document.

Regards,
Sascha

On Wed., Nov. 4, 2020, 19:15 Takahiko Kawasaki,  wrote:

> Hi Sascha,
>
> The change you found in the draft 04 is the change made to the JAR (JWT
> Secured Authorization Request). Now, "client_id" is mandatory. I summarized
> technical details about JAR in the article below. It describes the reasons
> for the necessity of "client_id". PAR is mentioned there, too.
>
> Implementer's note about JAR (JWT Secured Authorization Request)
> https://darutk.medium.com/implementers-note-about-jar-fff4cbd158fe
>
> Best Regards,
> Taka
>
> On Thu, Nov 5, 2020 at 11:33 AM Sascha Preibisch <
> saschapreibi...@gmail.com> wrote:
>
>> Hi all!
>>
>> A while ago I implemented draft 00 of this spec:
>> - https://tools.ietf.org/html/draft-ietf-oauth-par-04
>>
>> Now, in draft 04, I see that a request to the /authorize endpoint is
>> defined with client_id and request_uri. The client_id was added since draft
>> 00 (see: https://tools.ietf.org/html/draft-ietf-oauth-par-04#section-4).
>>
>> I am not sure if 'client_id' is now required, that's all.
>>
>> Thanks for clarification,
>>
>> regards,
>> Sascha
>> ___
>> 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] oauth par - authorize request with client_id

[Sascha Preibisch]

Hi all!

A while ago I implemented draft 00 of this spec:
- https://tools.ietf.org/html/draft-ietf-oauth-par-04

Now, in draft 04, I see that a request to the /authorize endpoint is
defined with client_id and request_uri. The client_id was added since draft
00 (see: https://tools.ietf.org/html/draft-ietf-oauth-par-04#section-4).

I am not sure if 'client_id' is now required, that's all.

Thanks for clarification,

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

Re: [OAUTH-WG] Implementation questions around refresh token rotation

[Sascha Preibisch]

In the past, customers brought to our attention that some clients were not
able to receive a new refresh_token and use it right away. For that use
case we added a different type of rotation. The new refresh_token was
exactly the same as the given one. Except that it had a new expiration
date, lifetime and such. It was usually tight to exactly one scope valid
scope value.
Since customers were able to configure this behaviour for specific clients,
they used this feature for single or a limited number of use cases.
Other than that, a used refresh_token became invalid once it was used with
no overlap.

Regards,
Sascha

On Sat, 10 Oct 2020 at 13:42, David Waite  wrote:

> On Oct 6, 2020, at 16:05, Aaron Parecki  wrote:
> > However that also kind of defeats the purpose since attacks within that
> grace period would be hard to detect. I'm looking for an idea of where
> people have landed on that issue in practice.
>
> This is effectively a race condition, and a grace period hides your
> ability to detect the race. Because of the race condition is no guarantee
> that the second refresh token is the one that is retained, the client could
> still fail once it needs its next access token.
>
> Instead, an ideal system would allow you to make a security exception and
> turn off rotation, possibly only until the client revises their logic.
>
> -DW
> ___
> 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] Call for adoption - OAuth 2.1 document

[Sascha Preibisch]

+1

On Thu, 16 Jul 2020 at 23:57, Vladimir Dzhuvinov
 wrote:
>
> +1
>
> Vladimir
>
> On 15/07/2020 20:54, Dick Hardt wrote:
>
> +1
>
> On Wed, Jul 15, 2020 at 10:42 AM Rifaat Shekh-Yusef  
> wrote:
>>
>> All,
>>
>> This is a call for adoption for the following OAuth 2.1 document as a WG 
>> document:
>> https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html
>>
>> Please, provide your feedback on the mailing list by July 29th.
>>
>> Regards,
>>  Rifaat & Hannes
>
>
> ___
> 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] Call for adoption - OAuth 2.1 document

[Sascha Preibisch]

+1

On Wed, 15 Jul 2020 at 13:40, Hans Zandbelt  wrote:
>
> +1
>
> Hans.
>
> On Wed, Jul 15, 2020 at 7:43 PM Rifaat Shekh-Yusef  
> wrote:
>>
>> All,
>>
>> This is a call for adoption for the following OAuth 2.1 document as a WG 
>> document:
>> https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html
>>
>> Please, provide your feedback on the mailing list by July 29th.
>>
>> Regards,
>>  Rifaat & Hannes
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> --
> hans.zandb...@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
> ___
> 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 2.1-03 - WG adoption?

[Sascha Preibisch]

Hello Dick!

Unless the two typos that I have mentioned should be updated beforehand ,
no, I do not.

Thank you,
Sascha

On Tue, 7 Jul 2020 at 16:36, Dick Hardt  wrote:

> Thanks Sascha and Vladimir for the feedback!
>
> Sascha: did you have a concern with the document being adopted by the WG?
>
> ᐧ
>
> On Tue, Jul 7, 2020 at 4:04 PM Sascha Preibisch 
> wrote:
>
>> Hi all!
>>
>> Here is the rest of my feedback. At the end I also included a list of
>> typos and the summary of changes that I have found between RFC 6739
>> and the current draft.
>>
>> Regards,
>> Sascha
>>
>> Section 2.3. Client Authentication
>> -
>>
>> Draft and current:
>> - both documents contain this description: "... the authorization
>> server (e.g., password, public/private key pair)"
>> - since the client usually uses a 'client secret', maybe this could be
>> worded as such:
>> - suggestion: "... the authorization server (e.g., client secret,
>> public/private key pair)"
>>
>> Draft:
>>
>> "The authorization server MAY establish a client authentication method
>> with public clients, which converts them to credentialed clients.
>> However, the authorization server MUST NOT rely on credentialed
>> client authentication for the purpose of identifying the client."
>>
>> - Does this mean that credentialed clients are as trustworthy/ not
>> trustworthy as public clients?
>>
>> Draft:
>>
>> "Clients in possession of a client password, also known as a client
>> secret, ..."
>>
>> - Maybe this could simply be changed to:
>> "Clients in possession of a client secret ..."
>>
>> Section 3.1.2.2 Registration Requirements
>> -
>>
>> Draft:
>>
>> "Lack of requiring registration of redirect URIs enables an attacker
>> to use the authorization endpoint as an open redirector as described
>> in Section 9.18."
>>
>> - is that still required since redirect_uris have to be pre-registered
>> now?
>>
>> Section 4.1. Authorization Code Grant
>> -
>>
>> Draft:
>> - Figure 3, step (1), does not include 'code_challenge_method' Is that
>> intentionally?
>> - I am suggesting to include it to avoid potential questions and
>> confusion. It could listed as 'optional' as 'scope' is
>> - In addition, when referencing parameters, they should be spelled as
>> used in the protocol, i.e.: 'code_challenge' instead of
>> 'code_challenge'
>>
>> Section 4.1.1 Authorization Request
>> -
>>
>> Draft:
>>
>> "Clients use a unique secret per authorization request to protect  "
>>
>> - It would be less confusing if this section would start of with "PKCE
>> is required"
>> - Introducing a '... unique secret per ...' sounds like something very
>> new although this is referencing PKCE
>> - Suggestion (along the lines of):
>> "Clients MUST leverage PKCE per authorization request to protect ..."
>>
>> Section 4.1.2.1 Error Response
>> -
>>
>> Draft:
>>
>> "An AS MUST reject requests without a "code_challenge" from public
>> clients, and MUST reject such requests from other clients  unless
>> there is reasonable assurance that ..."
>>
>> - These statements are the ones that cause discussions between
>> developers and/ or third parties
>> - ' ... unless ...' is very difficult to grasp, even when looking into
>> section 9.8
>> - I would suggest to make it required
>>
>> Section 5.1 Successful Response
>> -
>>
>> Draft and current:
>>
>> - both documents describe the refresh_token response parameter and
>> describe it as such:
>> "OPTIONAL.  The refresh token, which can be used to obtain new access
>> tokens using the same authorization grant as described in > href="#section-6">Section 6"
>>
>> - As an enhancement, I suggest this update:
>> "OPTIONAL.  The refresh token, which can be used to obtain new access
>> tokens using the grant type "refresh_token" as described in > href="#section-6">Section 6"
>>
>> Section 6. Refreshing an Access Token
>> -
>>
>> Draft:
>>
>> Authorization servers SHOULD determine, based on a risk assessment,
>> whether to issu

Re: [OAUTH-WG] OAuth 2.1-03 - WG adoption?

[Sascha Preibisch]

Hi all!

Here is the rest of my feedback. At the end I also included a list of
typos and the summary of changes that I have found between RFC 6739
and the current draft.

Regards,
Sascha

Section 2.3. Client Authentication
-

Draft and current:
- both documents contain this description: "... the authorization
server (e.g., password, public/private key pair)"
- since the client usually uses a 'client secret', maybe this could be
worded as such:
- suggestion: "... the authorization server (e.g., client secret,
public/private key pair)"

Draft:

"The authorization server MAY establish a client authentication method
with public clients, which converts them to credentialed clients.
However, the authorization server MUST NOT rely on credentialed
client authentication for the purpose of identifying the client."

- Does this mean that credentialed clients are as trustworthy/ not
trustworthy as public clients?

Draft:

"Clients in possession of a client password, also known as a client secret, ..."

- Maybe this could simply be changed to:
"Clients in possession of a client secret ..."

Section 3.1.2.2 Registration Requirements
-

Draft:

"Lack of requiring registration of redirect URIs enables an attacker
to use the authorization endpoint as an open redirector as described
in Section 9.18."

- is that still required since redirect_uris have to be pre-registered now?

Section 4.1. Authorization Code Grant
-

Draft:
- Figure 3, step (1), does not include 'code_challenge_method' Is that
intentionally?
- I am suggesting to include it to avoid potential questions and
confusion. It could listed as 'optional' as 'scope' is
- In addition, when referencing parameters, they should be spelled as
used in the protocol, i.e.: 'code_challenge' instead of
'code_challenge'

Section 4.1.1 Authorization Request
-

Draft:

"Clients use a unique secret per authorization request to protect  "

- It would be less confusing if this section would start of with "PKCE
is required"
- Introducing a '... unique secret per ...' sounds like something very
new although this is referencing PKCE
- Suggestion (along the lines of):
"Clients MUST leverage PKCE per authorization request to protect ..."

Section 4.1.2.1 Error Response
-

Draft:

"An AS MUST reject requests without a "code_challenge" from public
clients, and MUST reject such requests from other clients  unless
there is reasonable assurance that ..."

- These statements are the ones that cause discussions between
developers and/ or third parties
- ' ... unless ...' is very difficult to grasp, even when looking into
section 9.8
- I would suggest to make it required

Section 5.1 Successful Response
-

Draft and current:

- both documents describe the refresh_token response parameter and
describe it as such:
"OPTIONAL.  The refresh token, which can be used to obtain new access
tokens using the same authorization grant as described in Section 6"

- As an enhancement, I suggest this update:
"OPTIONAL.  The refresh token, which can be used to obtain new access
tokens using the grant type "refresh_token" as described in Section 6"

Section 6. Refreshing an Access Token
-

Draft:

Authorization servers SHOULD determine, based on a risk assessment,
whether to issue refresh tokens to a certain client.  If the
authorization server decides not to issue refresh tokens, the client
MAY refresh access tokens by utilizing other grant types, such as the
authorization code grant type.  In such a case, the authorization
server may utilize cookies and persistent grants to optimize the user
experience.

- That paragraph sounds like a general advice for web developers and
should appear in an appendix for my taste
- ' ... based on risk assessment ... ' may exclude any implementation
that does not have such capabilities

===

Draft:

- this section includes this statement:
"Confidential or credentialed clients MUST authenticate with the
authorization server ..."

- section 2.3 includes this statement and makes me wonder how
confident an authorization server can be when working with
'credentialed' clients':
"However, the authorization server MUST NOT rely on credentialed
client authentication for the purpose of identifying the client."

- Any clarification, I would say about the client type 'credentialed'
in general, would be helpful

-
Typos:
-

Section 2.1. Client Types
-

Draft:

"credentialed":  Clients that have credentials and their identity has
been not been confirmed by the AS are designated as "credentialed
clients"

- I believe it should be:

"credentialed":  Clients that have credentials and their identity has
not been confirmed by the AS are designated as "credentialed clients"

Section 3.2.1 Client Authentication
-

Draft:

"Confidential 

Re: [OAUTH-WG] OAuth 2.1-03 - WG adoption?

[Sascha Preibisch]

Hi all!

I am reading through this document for the first time. I am mainly
looking at it in comparison to OAuth 2.0 (RFC 6749) and with the eyes
of a developer. I am trying to understand where phrases have changed
and, of course, where features are changing.

What is the best way to provide feedback? In this mailing list?

Thanks,
Sascha

On Mon, 6 Jul 2020 at 09:44, Dick Hardt  wrote:
>
> Aaron, Torsten, and I -- with some help from Daniel -- have created a new 
> version of draft-pareck-oauth-v2-1. I think we are ready for a WG adoption 
> call (assuming the updated charter).
>
> Here is the doc:
>
> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-03
>
> Here is a link to the diff from -02:
>
> https://tools.ietf.org/rfcdiff?url2=draft-parecki-oauth-v2-1-03.txt
>
> This version incorporates feedback from the WG, as well as editorial changes 
> to improve readability. Highlights:
>
> - Appendix of current known extensions, and references to the Appendix so 
> that readers become aware of related work.
>
> - defined new client type - credentialed clients - a client that has 
> credentials, but the AS has not confirmed the identity of the client. 
> Confidential clients have had their identity confirmed by the AS. We talked 
> about changing the names of confidential and public, but thought that would 
> be confusing. This new definition cleans up the text substantially.
>
> - consistent use of redirect URI rather than mixing in redirect endpoint URI 
> and redirect endpoint.
>
> - adopted new language on when PKCE is required.
>
> - removed IANA section (nothing new is in 2.1)
>
> / Dick
>
>
>
> ___
> 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] Aligning PKCE requirements within the OAuth Security BCP

[Sascha Preibisch]

The document is called "...Best Current Practice ..." and includes
recommendations. Could it be sufficient to say "Authorization servers
support PKCE" in section 2.1.1?  I believe MUST and other such terms
may not necessarily belong into such document.

Regards,
Sascha

On Wed, 6 May 2020 at 14:04, Mike Jones
 wrote:
>
> As is being discussed in the thread “[OAUTH-WG] OAuth 2.1 - require PKCE?”, 
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1..1
>  has inconsistent requirements for PKCE support between clients and servers.  
> Per the first paragraph, clients must either use PKCE or use the OpenID 
> Connect nonce to prevent authorization code injection.  Whereas the fourth 
> paragraph says “Authorization servers MUST support PKCE [RFC7636].”.  This 
> imposes a requirement on servers that isn’t present for corresponding 
> clients.  (I missed this internal discrepancy within the specification when I 
> did my review.)
>
>
>
> I therefore request that the fourth paragraph by change to read: “OAuth 
> Servers MUST support PKCE [RFC7636] unless they are only used for OpenID 
> Connect Authentication Requests”, making the requirements on clients and 
> servers parallel.  That way PKCE will still be there unless you don’t need 
> it.  (And it still could be there if the server implementer chooses to have 
> it in all cases, but that should be their call.)
>
>
>
>Thank you,
>
>-- Mike
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] PAR - Guidance on the request URI structure needed?

[Sascha Preibisch]

+1

On Mon, 27 Apr 2020 at 01:42, Filip Skokan  wrote:
>
> I believe implementers should be free to devise their own URIs and not be 
> locked down to one by the spec, at the same time, and RFC6755 subnamespace 
> would be good for guidance.
>
> So, I would suggest it be RECOMMENDED to use e.g. 
> `urn:ietf:params:oauth:request_uri:` (Brian's proposal) but also that 
> any URN or URL will do if the circumstances call for it.
>
> Best,
> Filip
>
>
> On Sun, 26 Apr 2020 at 17:20, Torsten Lodderstedt 
>  wrote:
>>
>> Hi all,
>>
>> another topic from last week’s virtual meeting.
>>
>> Shall there be guidance on the request URI structure?
>>
>> Please state your opinion.
>>
>> thanks in advance,
>> Torsten.
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] PAR and client metadata

[Sascha Preibisch]

I am also in favour of such metadata.

I just implemented the draft and I used a client, which had multiple
redirect_uris, for testing purposes. That in mind, one of my thoughts
is that it could also be an advantage to not only bind a client to use
PAR but in combination with a specific redirect_uri only. This may be
a implementation detail of the AS, just wanted to mention it.

Regards,
Sascha

On Thu, 16 Apr 2020 at 01:16, Filip Skokan  wrote:
>
> I would support defining a client level property. I would also support an AS 
> discovery property for an AS-wide policy that is signalled to all clients 
> (and maybe that one would be enough).
>
> FWIW (and this touches my earlier responses about the dpop scheme) defining 
> metadata (both AS and Client) is beneficial not only for runtime (DCR, 
> discovery) but in general supports developers using these specs, when they 
> read about a possible behaviour in the document and there's a mentioned 
> metadata property, they know what to look for in readmes, API documentation, 
> UI etc. It saves time, theirs, and mine when i develop those behaviour 
> toggles - i don't have to start mixing configuration objects so far composed 
> entirely of IANA registered properties with proprietary ones, i don't need to 
> come up with property names (and we know what a PITA that is) and it also 
> saves time in the long run because it's less likely someone will open an 
> issue about it.
>
> Best,
> Filip
>
>
> On Tue, 14 Apr 2020 at 22:09, Brian Campbell 
>  wrote:
>>
>> Using PAR can facilitate improved security by giving clients a (relatively) 
>> simple means for sending a confidential, integrity protected, and (for 
>> confidential clients anyway) authenticated authorization request.
>>
>> It seems like some of that improved security could be undermined by a 
>> malicious actor somehow getting a user to navigate to a URL of a regular old 
>> parameterized authorization request. One variation of the Mix-Up Attack does 
>> this 
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
>>  for example and email, social media, online forums, etc., are other ways a 
>> user might be tricked into following a maliciously crafted link.
>>
>> Following from that it seems logical that an authorization server might want 
>> to restrict some clients from sending a regular parameterized authorization 
>> request and instead require use of the PAR endpoint to initiate an 
>> authorization request. Something like this could, of course, be implemented 
>> as custom policy or configuration in any AS. But I'm thinking it might be 
>> common enough to warrant adding a client metadata parameter to the PAR draft 
>> specifically for it. The metadata (and registered extensions) defined by 
>> Dynamic Client Registration [RFC7591] has come to imply a general data model 
>> and expected associated behaviors for clients that is useful for 
>> authorization server implementations, even when the Dynamic Client 
>> Registration Protocol isn't directly in play. This particular situation 
>> seems like a good potential candidate for a new such client metadata 
>> parameter that would indicate that the given client can only use a 
>> request_uri value obtained from the PAR endpoint to initia
 te an authorization request. And that a regular old fashioned authorization 
request from the given client would result in an error.
>>
>> Do the folks of this fine WG think something like this would be a worthwhile 
>> addition to the PAR draft?
>>
>>
>>
>>
>>
>> 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

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

Re: [OAUTH-WG] Corona Virus and Vancouver

[Sascha Preibisch]

I will be there if it is not getting worse. But in any case I am in
Vancouver.

Regards,
Sascha

On Mon., Mar. 9, 2020, 11:35 Daniel Fett,  wrote:

> Hi all,
>
> can we do a quick roll call on who is coming or not coming to Vancouver?
>
> For me, at the current point in time, it depends on whether a significant
> portion of the working group is attending in-person.
>
> -Daniel
> ___
> 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] New OAuth DPoP and Security BCP drafts

[Sascha Preibisch]

Hi all!

I am reading through the latest draft ( ... dpop-02). When I got to
the first example request (bullet 5.) I saw that only 'grant_type,
code, redirect_uri' are used.

If I am not mistaken the recommendation is to generally use PKCE with
an authorization_code flow. Therefore, I wondered if the example
should also include a 'code_verifier'.

Thanks,
Sascha

On Mon, 8 Jul 2019 at 06:30, Daniel Fett  wrote:
>
> All,
>
> In preparation for the meeting in Montreal, I just uploaded a new version of 
> the DPoP draft:
> https://tools.ietf.org/html/draft-fett-oauth-dpop-02
>
> Please have a look and let me know what you think. We should make this a 
> working group item soon.
>
> As you might have noticed, there is also a new version of the Security Best 
> Current Practice draft:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13
>
> -Daniel
> ___
> 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] Transaction Authorization with OAuth

[Sascha Preibisch]

Torsten,

I think that works in most cases if you look at it that way.

It is just that elements such as 'iban' are practically unknown here
in Canada for example. This means, there needs to be a differentiator
that tells a client that one payment may be of type 'payment_eu' and
in the other case 'payment_ca'. Actually  now I see the 'type'
element. With that, 'payment + type' would provide that information.

The only thing I would look into would be a change in the document
hierarchy to simply parsing of it. Potentially multiple payments could
be submitted at once also by adding a 'payments' root element:

{
"payment": {
"sepa-credit-transfer": {
"instructedAmount": {
"currency": "EUR",
"amount": "123.50"
},
"debtorAccount": {
"iban": "DE40100100103307118608"
},
"creditorName": "Merchant123",
"creditorAccount": {
"iban": "DE02100100109307118603"
},
"remittanceInformationUnstructured": "new Smartphone"
}
}
}

But generally, the 'structured_scope' is a good concept I think.

Thanks again, Torsten,

Sascha

Am Mi., 24. Apr. 2019 um 10:08 Uhr schrieb Torsten Lodderstedt
:
>
> Hi Sascha,
>
> I see. I assume every element within the structured scope element to be an 
> independent scope (value) object and intended to use the name of that object 
> as kind of content type definition.
>
> In my last example, the scope is defined as
>
>"structured_scope":{
>   "sign":{
>  "credentialID":"qes_eidas",
>  "documentDigests":[
> {
>"hash":
>  "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
>"label":"Mobile Subscription Contract"
> }
>  ],
>  "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
>   },
>   "payment":{
>  "type":"sepa-credit-transfer",
>  "instructedAmount":{
> "currency":"EUR",
> "amount":"123.50"
>  },
>  "debtorAccount":{
> "iban":"DE40100100103307118608"
>  },
>  "creditorName":"Merchant123",
>  "creditorAccount":{
> "iban":"DE02100100109307118603"
>  },
>  "remittanceInformationUnstructured":"new Smartphone"
>   }
>
> This means “sign" and “payment" would determine the scheme of the respective 
> object.
>
> What do you think?
>
> best regards,
> Torsten.
>
> > On 23. Apr 2019, at 17:14, Sascha Preibisch  
> > wrote:
> >
> > Hi Torsten!
> >
> > If 'structured_scope' would become a generic field for application
> > specific content, I believe an indicator for the type of content would
> > be needed on the long run. That is what I meant my 'profile'. I hope
> > this helps!
> >
> > Thank you,
> > Sascha
> >
> > Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
> > :
> >>
> >> Hi Sascha,
> >>
> >>> Am 22.04.2019 um 20:34 schrieb Sascha Preibisch 
> >>> :
> >>>
> >>> Thank you for the article, Torsten!
> >>
> >> my pleasure :-)
> >>
> >>>
> >>> I like that 'scope' is out of the game for these kinds of authorizations.
> >>>
> >>> What I can see for the general use case is a required identifier
> >>> within the 'structures_scope' document that identifies the profile it
> >>> should be used for.
> >>
> >> What does profile mean in this context?
> >>
> >> best regards,
> >> Torsten.
> >>>
> >>> Thank you,
> >>> Sascha
> >>>
> >>> Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
> >>> :
> >>>>
> >>>> Hi all,
> >>>>
> >>>> I just published an article about the subject at: 
> >>>> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
> >>>>
> >>>> I look forward to getting your feedback.
> >>>>
> >>>> kind regards,
> >>>> Torsten.
> >>>> ___
> >>>> 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] Transaction Authorization with OAuth

[Sascha Preibisch]

Hi Torsten!

If 'structured_scope' would become a generic field for application
specific content, I believe an indicator for the type of content would
be needed on the long run. That is what I meant my 'profile'. I hope
this helps!

Thank you,
Sascha

Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
:
>
> Hi Sascha,
>
> > Am 22.04.2019 um 20:34 schrieb Sascha Preibisch :
> >
> > Thank you for the article, Torsten!
>
> my pleasure :-)
>
> >
> > I like that 'scope' is out of the game for these kinds of authorizations.
> >
> > What I can see for the general use case is a required identifier
> > within the 'structures_scope' document that identifies the profile it
> > should be used for.
>
> What does profile mean in this context?
>
> best regards,
> Torsten.
> >
> > Thank you,
> > Sascha
> >
> > Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
> > :
> >>
> >> Hi all,
> >>
> >> I just published an article about the subject at: 
> >> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
> >>
> >> I look forward to getting your feedback.
> >>
> >> kind regards,
> >> Torsten.
> >> ___
> >> 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] Transaction Authorization with OAuth

[Sascha Preibisch]

Thank you for the article, Torsten!

I like that 'scope' is out of the game for these kinds of authorizations.

What I can see for the general use case is a required identifier
within the 'structures_scope' document that identifies the profile it
should be used for.

Thank you,
Sascha

Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
:
>
> Hi all,
>
> I just published an article about the subject at: 
> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>
> I look forward to getting your feedback.
>
> kind regards,
> Torsten.
> ___
> 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] Call for adoption: JWT Usage in OAuth2 Access Tokens

[Sascha Preibisch]

Thanks, Martin!

I understand. I just think it is difficult to get this adopted if
clients now have to include the target resource in their request in
order to place that into the 'aud' field. Unless the client has
somehow registered its intended protected resources beforehand the
authorization server cannot set an appropriate value if it was not
passed in as a request parameter.

Thanks,
Sascha

Am Sa., 13. Apr. 2019 um 09:29 Uhr schrieb Schanzenbach, Martin
:
>
>
>
> > On 10. Apr 2019, at 19:39, Sascha Preibisch  
> > wrote:
> >
> > I am late in the game, but not too late I hope.
> >
> > I would like to see 'aud' be the requesting client_id. For identifying the 
> > the target resource, a 'resource' claim should be introduced. I am also 
> > suggesting to not introduce 'typ: at+jwt'. It is simply a jwt and the 
> > validation process will show if it is an access_token or not.
>
> "aud = client_id" would mean that, by definition, the JWT must not be 
> presented to any other entity than the client. This makes only sense for the 
> ID Token in OIDC I think.  OTOH, defining a JWT which can be presented by the 
> client to the RS is the whole point of this draft.
> Also, the reason why it makes sense to introduce a new type is that an OIDC 
> ID Token _could_ be mistaken for an AT (which it isn't).
> IMO it might even make sense to encourage the OIDC spec to change to jwt+id 
> or something by extending the JWT spec.
>
> I also support the adoption.
>
> >
> > Last but not least, 'aud' (as resource identifier) should not be required. 
> > Requiring that, and the requested resource in the the token request, will 
> > require existing clients to be updated. Introducing jwt access_token should 
> > be transparent to clients.
> >
> > Thanks,
> > Sascha
> >
> >
> > On Wed., Apr. 10, 2019, 06:41 n-sakimura,  wrote:
> > +1
> >
> > For that matter, explicit typing is good and I am a bit ambivalent on the 
> > use of `sub`.
> >
> > Also, I need to add the 4th consideration: Although the current privacy 
> > consideration is stating about the encryption, it is in relation to the end 
> > user exposure. In fact, the by-value access token when involving some PII 
> > is by definition leaking information and violating the data minimization 
> > principle. This should be clearly delineated. My gut feeling is that it 
> > should be encrypted unless it is certain that it does not include sensitive 
> > PII as judging whether a claim may form a PII is too hard for an average 
> > developer..
> >
> > -Original Message-
> > From: OAuth  On Behalf Of Anthony Nadalin
> > Sent: Wednesday, April 10, 2019 8:12 PM
> > To: Hannes Tschofenig ; oauth@ietf.org
> > Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
> >
> > I support adoption of this draft as a working group document with the 
> > following caveats:
> >
> > 1. These are not to be used as ID Tokens/authentication tokens 2. The 
> > privacy issues must be addressed 3. Needs to be extensible, much like 
> > ID-Token, can't be 100% fixed
> >
> >
> > -Original Message-
> > From: OAuth  On Behalf Of Hannes Tschofenig
> > Sent: Monday, April 8, 2019 10:07 AM
> > To: oauth@ietf.org
> > Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
> >
> > Hi all,
> >
> > this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'  
> > document following the positive feedback at the last IETF meeting in Prague.
> >
> > Here is the document:
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-bertocci-oauth-access-token-jwt-00data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616347061sdata=ePmwaD%2FHCRZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3Dreserved=0
> >
> > Please let us know by April 22nd whether you accept / object to the 
> > adoption of this document as a starting point for work in the OAuth working 
> > group.
> >
> > Ciao
> > Hannes & Rifaat
> >
> > IMPORTANT NOTICE: The contents of this email and any attachments are 
> > confidential and may also be privileged. If you are not the intended 
> > recipient, please notify the sender immediately and do not disclose the 
> > contents to any other person, use it for any purpose, or store or copy the 
> > information in any medium. Thank you.
> >
> > _

Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

[Sascha Preibisch]

I am late in the game, but not too late I hope.

I would like to see 'aud' be the requesting client_id. For identifying the
the target resource, a 'resource' claim should be introduced. I am also
suggesting to not introduce 'typ: at+jwt'. It is simply a jwt and the
validation process will show if it is an access_token or not.

Last but not least, 'aud' (as resource identifier) should not be required.
Requiring that, and the requested resource in the the token request, will
require existing clients to be updated. Introducing jwt access_token should
be transparent to clients.

Thanks,
Sascha


On Wed., Apr. 10, 2019, 06:41 n-sakimura,  wrote:

> +1
>
> For that matter, explicit typing is good and I am a bit ambivalent on the
> use of `sub`.
>
> Also, I need to add the 4th consideration: Although the current privacy
> consideration is stating about the encryption, it is in relation to the end
> user exposure. In fact, the by-value access token when involving some PII
> is by definition leaking information and violating the data minimization
> principle. This should be clearly delineated. My gut feeling is that it
> should be encrypted unless it is certain that it does not include sensitive
> PII as judging whether a claim may form a PII is too hard for an average
> developer.
>
> -Original Message-
> From: OAuth  On Behalf Of Anthony Nadalin
> Sent: Wednesday, April 10, 2019 8:12 PM
> To: Hannes Tschofenig ; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access
> Tokens
>
> I support adoption of this draft as a working group document with the
> following caveats:
>
> 1. These are not to be used as ID Tokens/authentication tokens 2. The
> privacy issues must be addressed 3. Needs to be extensible, much like
> ID-Token, can't be 100% fixed
>
>
> -Original Message-
> From: OAuth  On Behalf Of Hannes Tschofenig
> Sent: Monday, April 8, 2019 10:07 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
>
> Hi all,
>
> this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'
> document following the positive feedback at the last IETF meeting in Prague.
>
> Here is the document:
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools..ietf.org%2Fhtml%2Fdraft-bertocci-oauth-access-token-jwt-00data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616347061sdata=ePmwaD%2FHCRZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3Dreserved=0
>
> Please let us know by April 22nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth working
> group.
>
> Ciao
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> ___
> OAuth mailing list
> OAuth@ietf.org
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauthdata=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616357060sdata=zcxw1IR3kNbuZ9u58OOJDv9pLb7cUCooDtlIUH7tS%2Fw%3Dreserved=0
>
> ___
> 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