[OAUTH-WG] Protocol Action: 'OAuth 2.0 Authorization Server Issuer Identification' to Proposed Standard (draft-ietf-oauth-iss-auth-resp-04.txt)

[The IESG]

The IESG has approved the following document:
- 'OAuth 2.0 Authorization Server Issuer Identification'
  (draft-ietf-oauth-iss-auth-resp-04.txt) as Proposed Standard

This document is the product of the Web Authorization Protocol Working Group.

The IESG contact persons are Benjamin Kaduk and Roman Danyliw.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/





Technical Summary

   This document specifies a new parameter iss that is used to
   explicitly include the issuer identifier of the authorization server
   in the authorization response of an OAuth authorization flow.  The
   iss parameter serves as an effective countermeasure to "mix-up
   attacks".

Working Group Summary

This work is useful to address a specific attack when an OAuth Client interacts 
with multiple authorization servers.  It hardens prior OAuth works.

Document Quality

A number of people reviewed the document over several rounds of reviews and
provided feedback during meetings and on the mailing list, with no blocking
comments.

Implementations:

Duende Software
https://duendesoftware.com/products/identityserver

Authlete

https://www.authlete.com/developers/relnotes/2.2.2/#oauth-2-0-authorization-server-issuer-identifier-in-authorization-response

Authress
https://authress.io/


Personnel

The document shepherd is Rifaat Shekh-Yusef.

The responsible Area Director is Roman Danyliw.

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

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

[Thomas Broyer]

On Wed, Jan 5, 2022 at 5:51 PM George Fletcher  wrote:

> So it seems to me, two factors need to be present for something "bad" to
> happen...
>
> 1. The client always sends PKCE but the AS doesn't require the client to
> use PKCE
> 2. The client must accept uninitiated authorization response messages
> (i.e. from the attacker)
>

Not necessarily for that second point, but it must accept authorization
response messages without state.
The user can be triggered to initiate the authorization process (resulting
in the client storing some state in a cookie/session), so that when the
authorization response message comes in with the attacker-supplied
authorization_code, the client accepts it (cookie/session is present, so
it's not deemed "uninitiated")
Mitigation is to use state in addition to PKCE.

If either of the above are not true, then I think any attack fails. Please
> correct me if I'm wrong.
>
> Mitigations then are...
> 1. AS requires designated clients to always provide PKCE parameters and
> fails the /authorization request if they are not present
> 2. The client does not accept uninitiated authorization response messages
>
> It's best if both mitigations are implemented along with others identified
> in this thread.
>
> My 2 cents:)
>
> Thanks,
> George
>
> On 1/5/22 10:24 AM, Warren Parad wrote:
>
> The PKCE downgrade attack is the converse, here we are adding in PKCE
> where there was none.
>
> An attacker can thus send the victim the authorization response, after the
>> victim clicks the link, the client application sends a Token Request with
>> the code_verifier present with the client to Keycloak.
>
> That isn't the whole flow though, right? You are missing what the
> authorization request the attacker sent to the AS is, as well what happens
> after the user agent gets back the access token, how is a token generated
> this way a vulnerability.
>
> I think I see the suggested problem:
>
> if an AS-client interaction supports both PKCE and not PKCE, and the
> client assumes that PKCE is sufficient for CSRF, when the auth code request
> doesn't include the PKCE but the client didn't send state/nonce. With OAuth
> 2.1 it is clear that the nonce/state must be sent in this situation:
>
>- State is required in OAuth authorization code requests if PKCE isn't
>specified: OAuth 2.1 section 7.7
>
> 
>- State is required in OAuth token exchange requests if present: Section
>4.1.2
>
> 
>
> Since the user agent won't contain the valid state/nonce generated by the
> attacker, it isn't possible for it to send the attacker's state to the AS.
> Therefore the AS will reject the token exchange due to the state mismatch.
> It doesn't matter if the request isn't protected against CSRF, because no
> valid token is going to be returned anyway.
>
> So I don't think there is an issue here, did I get that correct?
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress .
>
>
> On Wed, Jan 5, 2022 at 3:56 PM Christopher Burroughs <
> chris.burrou...@protonmail.ch> wrote:
>
>> Greetings,
>>
>>
>> Is this scenario any different from a PKCE downgrade attack, as described
>> in OAuth 2.0 Security Best Current Practice section 4.8.2 ?
>>
>>
>> Warm regards and happy new year!
>>
>>
>> Christopher Burroughs
>>
>>
>>
>>
>>
>>  Original Message 
>> On Jan 5, 2022, 21:29, Benjamin Häublein < benjamin.haeubl...@cirosec.de>
>> wrote:
>>
>>
>> The following example shows this behavior in keycloak:
>>
>> Authorization Request:
>>
>>
>> http://identity-provider:8080/auth/realms/XXX/protocol/openid-connect/auth?client_id=client-spa-public-pkce_uri=http%3A%2F%2Flocalhost%2F_mode=fragment_type=code=openid
>>
>> Authorization Response:
>>
>>
>> http://127.0.0.1/#session_state=46556363-c53f-489f-871c-58d376a8f9c1=2b84ee14-68ff-48c9-b480-4349ff9805f7.46556363-c53f-489f-871c-58d376a8f9c1.6fab0727-6184-47ad-8607-55f19896e945
>>
>> Token Request:
>>
>> POST /auth/realms/XXX/protocol/openid-connect/token HTTP/1.1
>> Host: identity-provider:8080
>> Content-type: application/x-www-form-urlencoded
>>
>>
>> code=2b84ee14-68ff-48c9-b480-4349ff9805f7.46556363-c53f-489f-871c-58d376a8f9c1.6fab0727-6184-47ad-8607-55f19896e945_type=authorization_code_id=client-spa-public-pkce_uri=http%3A%2F%2Flocalhost%2F_verifier=IqiCQGM06JEyW73AB3f3oblCQKHOorapyqHUcYRujuSikDJx8cvBQ0kmFmzW75uIfaSBtXQrRmwuk71WWO6ryCzahTcxBPYX
>>
>>
>>
>> As a result, an access token was issued although the code_verifier
>> provided in the token request did not match the code_challenge and
>> code_challenge_method in the authorization request as they were absent.
>>
>>
>>
>> An attacker can thus send the victim the authorization response, after
>> the victim clicks the link, the client application sends a Token Request

Re: [OAUTH-WG] [Editorial Errata Reported] RFC8707 (6810)

[Brian Campbell]

Seems legit.

On Wed, Jan 5, 2022 at 5:03 AM RFC Errata System 
wrote:

> The following errata report has been submitted for RFC8707,
> "Resource Indicators for OAuth 2.0".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6810
>
> --
> Type: Editorial
> Reported by: Jan Goebel 
>
> Section: 4
>
> Original Text
> -
> In typical OAuth deployments the authorization sever is in a position
> to observe and track a significant amount of user and client behavior.
>
> Corrected Text
> --
> In typical OAuth deployments, the authorization server is in a position
> to observe and track a significant amount of user and client behavior.
>
> Notes
> -
> 1. typo: sever -> server
> 2. I think we also need a comma after "In typical OAuth deployments"
> because it is an introductory phrase, but maybe a native English speaker
> can confirm.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8707 (draft-ietf-oauth-resource-indicators-08)
> --
> Title   : Resource Indicators for OAuth 2.0
> Publication Date: February 2020
> Author(s)   : B. Campbell, J. Bradley, H. Tschofenig
> Category: PROPOSED STANDARD
> Source  : Web Authorization Protocol
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> 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

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

[George Fletcher]

So it seems to me, two factors need to be present for something "bad" to 
happen...


1. The client always sends PKCE but the AS doesn't require the client to 
use PKCE
2. The client must accept uninitiated authorization response messages 
(i.e. from the attacker)


If either of the above are not true, then I think any attack fails. 
Please correct me if I'm wrong.


Mitigations then are...
1. AS requires designated clients to always provide PKCE parameters and 
fails the /authorization request if they are not present

2. The client does not accept uninitiated authorization response messages

It's best if both mitigations are implemented along with others 
identified in this thread.


My 2 cents:)

Thanks,
George

On 1/5/22 10:24 AM, Warren Parad wrote:
The PKCE downgrade attack is the converse, here we are adding in PKCE 
where there was none.


An attacker can thus send the victim the authorization response,
after the victim clicks the link, the client application sends a
Token Request with the code_verifier present with the client to
Keycloak.

That isn't the whole flow though, right? You are missing what the 
authorization request the attacker sent to the AS is, as well what 
happens after the user agent gets back the access token, how is a 
token generated this way a vulnerability.


I think I see the suggested problem:

if an AS-client interaction supports both PKCE and not PKCE, and the 
client assumes that PKCE is sufficient for CSRF, when the auth code 
request doesn't include the PKCE but the client didn't send 
state/nonce. With OAuth 2.1 it is clear that the nonce/state must be 
sent in this situation:


  * State is required in OAuth authorization code requests if PKCE
isn't specified: OAuth 2.1 section 7.7

  * State is required in OAuth token exchange requests if present:
Section 4.1.2



Since the user agent won't contain the valid state/nonce generated by 
the attacker, it isn't possible for it to send the attacker's state to 
the AS. Therefore the AS will reject the token exchange due to the 
state mismatch. It doesn't matter if the request isn't protected 
against CSRF, because no valid token is going to be returned anyway.


So I don't think there is an issue here, did I get that correct?



Warren Parad

Founder, CTO

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



On Wed, Jan 5, 2022 at 3:56 PM Christopher Burroughs 
 wrote:


Greetings,


Is this scenario any different from a PKCE downgrade attack, as
described in OAuth 2.0 Security Best Current Practice section 4.8.2 ?


Warm regards and happy new year!


Christopher Burroughs





 Original Message 
On Jan 5, 2022, 21:29, Benjamin Häublein <
benjamin.haeubl...@cirosec.de> wrote:


The following example shows this behavior in keycloak:

Authorization Request:


http://identity-provider:8080/auth/realms/XXX/protocol/openid-connect/auth?client_id=client-spa-public-pkce_uri=http%3A%2F%2Flocalhost%2F_mode=fragment_type=code=openid



Authorization Response:


http://127.0.0.1/#session_state=46556363-c53f-489f-871c-58d376a8f9c1=2b84ee14-68ff-48c9-b480-4349ff9805f7.46556363-c53f-489f-871c-58d376a8f9c1.6fab0727-6184-47ad-8607-55f19896e945



Token Request:

POST /auth/realms/XXX/protocol/openid-connect/token HTTP/1.1
Host: identity-provider:8080
Content-type: application/x-www-form-urlencoded


code=2b84ee14-68ff-48c9-b480-4349ff9805f7.46556363-c53f-489f-871c-58d376a8f9c1.6fab0727-6184-47ad-8607-55f19896e945_type=authorization_code_id=client-spa-public-pkce_uri=http%3A%2F%2Flocalhost%2F_verifier=IqiCQGM06JEyW73AB3f3oblCQKHOorapyqHUcYRujuSikDJx8cvBQ0kmFmzW75uIfaSBtXQrRmwuk71WWO6ryCzahTcxBPYX

As a result, an access token was issued although the
code_verifier provided in the token request did not match the
code_challenge and code_challenge_method in the authorization
request as they were absent.

An attacker can thus send the victim the authorization
response, after the victim clicks the link, the client
application sends a Token Request with the code_verifier
present with the client to Keycloak.

As a result, a token is issued for the application, although
the code_verifier does not match the inexistent

Re: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-iss-auth-resp-03: (with COMMENT)

[Rob Wilton (rwilton)]

Hi Roman,

Thanks for getting back to me - I'm somewhat out of my depth here, but really I 
think that I find this sentence to be somewhat ambiguous:  "the use and 
verification of the iss parameter is not necessary and MAY be omitted."

I read this as allowing both:
 (i) a send can choose to not include the iss parameter (under the given 
scenarios).
 (ii) a receiver can choose to not verify the iss parameter (under the given 
scenarios).

>From you comments below, I think that the text is only intended to mean (i). 
>If so, perhaps the sentence would be clearer as just "the iss parameter is not 
>necessary and MAY be omitted"?

But if you feel the that text is sufficiently clear that is also okay with me.

Thanks,
Rob


> -Original Message-
> From: iesg  On Behalf Of Roman Danyliw
> Sent: 05 January 2022 15:13
> To: Rob Wilton (rwilton) ; The IESG 
> Cc: oauth-cha...@ietf.org; oauth@ietf.org; draft-ietf-oauth-iss-auth-
> r...@ietf.org
> Subject: RE: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-
> iss-auth-resp-03: (with COMMENT)
> 
> Hi Rob!
> 
> Thanks for your review. I wanted to close the loop on your COMMENT.  See
> below.
> 
> > -Original Message-
> > From: OAuth  On Behalf Of Robert Wilton via
> > Datatracker
> > Sent: Tuesday, November 30, 2021 5:31 AM
> > To: The IESG 
> > Cc: oauth@ietf.org; draft-ietf-oauth-iss-auth-r...@ietf.org; oauth-
> > cha...@ietf.org
> > Subject: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-iss-
> > auth-resp-03: (with COMMENT)
> >
> > Robert Wilton has entered the following ballot position for
> > draft-ietf-oauth-iss-auth-resp-03: No Objection
> >
> > When responding, please keep the subject line intact and reply to all email
> > addresses included in the To and CC lines. (Feel free to cut this 
> > introductory
> > paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> > for more information about how to handle DISCUSS and COMMENT
> positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > Hi,
> >
> > Thanks for this document, just one comment on a couple of sentences in
> the
> > security section that I found unclear in this paragraph:
> >
> >There are also alternative countermeasures to mix-up attacks.  When
> >an authorization response already includes an authorization server's
> >issuer identifier by other means, and this identifier is checked as
> >laid out in Section 2.4, the use and verification of the iss
> >parameter is not necessary and MAY be omitted.  This is the case when
> >OpenID Connect response types that return an ID token from the
> >authorization endpoint (e.g., response_type=code id_token) or JARM
> >response mode are used, for example.  However, if a client receives
> >an authorization response that contains multiple issuer identifiers,
> >the client MUST reject the response if these issuer identifiers do
> >not match.  The details of alternative countermeasures are outside of
> >the scope of this specification.
> >
> > I'm probably missing something but this seems to suggest both:
> >  - the use and verification of the iss parameter is not necessary and MAY be
> > omitted. - if a client receives an authorization response that contains
> multiple
> > issuer identifiers,
> >the client MUST reject the response if these issuer identifiers do not
> match.
> 
> Indeed, both are suggested courses of action, but across three scenarios:
> 
> (a) one iss which gets compared against the server's metadata document
> (paragraph 2 of Section 2.4)
> (b) no iss is present because there is a OpenIDConnect ID token or JARM JWT
> (both mechanisms provide a nearly equivalent mitigation to "iss", see last
> three paragraphs of Section 2.4)
> (c) multiple iss where the above behavior applies for rejection if they don't
> match; and also checks per (a) (this text)
> 
> Regards,
> Roman

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

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

[Warren Parad]

The PKCE downgrade attack is the converse, here we are adding in PKCE where
there was none.

An attacker can thus send the victim the authorization response, after the
> victim clicks the link, the client application sends a Token Request with
> the code_verifier present with the client to Keycloak.

That isn't the whole flow though, right? You are missing what the
authorization request the attacker sent to the AS is, as well what happens
after the user agent gets back the access token, how is a token generated
this way a vulnerability.

I think I see the suggested problem:

if an AS-client interaction supports both PKCE and not PKCE, and the client
assumes that PKCE is sufficient for CSRF, when the auth code request
doesn't include the PKCE but the client didn't send state/nonce. With OAuth
2.1 it is clear that the nonce/state must be sent in this situation:

   - State is required in OAuth authorization code requests if PKCE isn't
   specified: OAuth 2.1 section 7.7
   
   - State is required in OAuth token exchange requests if present: Section
   4.1.2
   


Since the user agent won't contain the valid state/nonce generated by the
attacker, it isn't possible for it to send the attacker's state to the AS.
Therefore the AS will reject the token exchange due to the state mismatch.
It doesn't matter if the request isn't protected against CSRF, because no
valid token is going to be returned anyway.

So I don't think there is an issue here, did I get that correct?

Warren Parad

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


On Wed, Jan 5, 2022 at 3:56 PM Christopher Burroughs <
chris.burrou...@protonmail.ch> wrote:

> Greetings,
>
>
> Is this scenario any different from a PKCE downgrade attack, as described
> in OAuth 2.0 Security Best Current Practice section 4.8.2 ?
>
>
> Warm regards and happy new year!
>
>
> Christopher Burroughs
>
>
>
>
>
>  Original Message 
> On Jan 5, 2022, 21:29, Benjamin Häublein < benjamin.haeubl...@cirosec.de>
> wrote:
>
>
> The following example shows this behavior in keycloak:
>
> Authorization Request:
>
>
> http://identity-provider:8080/auth/realms/XXX/protocol/openid-connect/auth?client_id=client-spa-public-pkce_uri=http%3A%2F%2Flocalhost%2F_mode=fragment_type=code=openid
>
> Authorization Response:
>
>
> http://127.0.0.1/#session_state=46556363-c53f-489f-871c-58d376a8f9c1=2b84ee14-68ff-48c9-b480-4349ff9805f7.46556363-c53f-489f-871c-58d376a8f9c1.6fab0727-6184-47ad-8607-55f19896e945
>
> Token Request:
>
> POST /auth/realms/XXX/protocol/openid-connect/token HTTP/1.1
> Host: identity-provider:8080
> Content-type: application/x-www-form-urlencoded
>
>
> code=2b84ee14-68ff-48c9-b480-4349ff9805f7.46556363-c53f-489f-871c-58d376a8f9c1.6fab0727-6184-47ad-8607-55f19896e945_type=authorization_code_id=client-spa-public-pkce_uri=http%3A%2F%2Flocalhost%2F_verifier=IqiCQGM06JEyW73AB3f3oblCQKHOorapyqHUcYRujuSikDJx8cvBQ0kmFmzW75uIfaSBtXQrRmwuk71WWO6ryCzahTcxBPYX
>
>
>
> As a result, an access token was issued although the code_verifier
> provided in the token request did not match the code_challenge and
> code_challenge_method in the authorization request as they were absent.
>
>
>
> An attacker can thus send the victim the authorization response, after the
> victim clicks the link, the client application sends a Token Request with
> the code_verifier present with the client to Keycloak.
>
> As a result, a token is issued for the application, although the
> code_verifier does not match the inexistent
> code_challenge/code_challenge_method in the malicious authorization
> response.
>
>
>
> For this to work, the client must either generate a code_verifier on the
> fly or have one already present. This obviously depends on the precise
> implementation of the respective client.
>
> To reach such a state, an attacker could trick the user into starting the
> authorization grant but clicking the malicious link before the
> authorization response is sent.
>
>
>
> Best Regards,
>
> Benjamin Häublein
> Senior Consultant
>
> cirosec GmbH
> Ferdinand-Braun-Strasse 4
> 74074 Heilbronn
> Germany
> Phone: +49 (7131) 59455-74
> Fax: +49 (7131) 59455-99
> Mobile: +49 (151) 122414-74
> www.cirosec.de
>
> HRB Stuttgart 107883
> CEO Stefan Strobel, CFO Peter Lips
>
>
>
> *Von:* Warren Parad 
> *Gesendet:* Mittwoch, 5. Januar 2022 13:44
> *An:* Benjamin Häublein 
> *Cc:* George Fletcher ; oauth@ietf.org
> *Betreff:* Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies
> code_verifier facilitates Login-CSRF
>
>
>
> Sie erhalten nicht oft E-Mail von "wpa...@rhosys.ch". Weitere
> Informationen, warum dies wichtig ist
> 
>
> I'm not following to be honest. Could you detail concretely what the flow
> would be that would result in 

Re: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-iss-auth-resp-03: (with COMMENT)

[Roman Danyliw]

Hi Rob!

Thanks for your review. I wanted to close the loop on your COMMENT.  See below.

> -Original Message-
> From: OAuth  On Behalf Of Robert Wilton via
> Datatracker
> Sent: Tuesday, November 30, 2021 5:31 AM
> To: The IESG 
> Cc: oauth@ietf.org; draft-ietf-oauth-iss-auth-r...@ietf.org; oauth-
> cha...@ietf.org
> Subject: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-iss-
> auth-resp-03: (with COMMENT)
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-oauth-iss-auth-resp-03: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Hi,
> 
> Thanks for this document, just one comment on a couple of sentences in the
> security section that I found unclear in this paragraph:
> 
>There are also alternative countermeasures to mix-up attacks.  When
>an authorization response already includes an authorization server's
>issuer identifier by other means, and this identifier is checked as
>laid out in Section 2.4, the use and verification of the iss
>parameter is not necessary and MAY be omitted.  This is the case when
>OpenID Connect response types that return an ID token from the
>authorization endpoint (e.g., response_type=code id_token) or JARM
>response mode are used, for example.  However, if a client receives
>an authorization response that contains multiple issuer identifiers,
>the client MUST reject the response if these issuer identifiers do
>not match.  The details of alternative countermeasures are outside of
>the scope of this specification.
> 
> I'm probably missing something but this seems to suggest both:
>  - the use and verification of the iss parameter is not necessary and MAY be
> omitted. - if a client receives an authorization response that contains  
> multiple
> issuer identifiers,
>the client MUST reject the response if these issuer identifiers do not 
> match.

Indeed, both are suggested courses of action, but across three scenarios:

(a) one iss which gets compared against the server's metadata document 
(paragraph 2 of Section 2.4)
(b) no iss is present because there is a OpenIDConnect ID token or JARM JWT 
(both mechanisms provide a nearly equivalent mitigation to "iss", see last 
three paragraphs of Section 2.4)
(c) multiple iss where the above behavior applies for rejection if they don't 
match; and also checks per (a) (this text)

Regards,
Roman

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

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

[Christopher Burroughs]

Greetings,

Is this scenario any different from a PKCE downgrade attack, as described in 
OAuth 2.0 Security Best Current Practice section 4.8.2 ?

Warm regards and happy new year!

Christopher Burroughs

 Original Message 
On Jan 5, 2022, 21:29, Benjamin Häublein wrote:

> The following example shows this behavior in keycloak:
>
> Authorization Request:
>
> http://identity-provider:8080/auth/realms/XXX/protocol/openid-connect/auth?client_id=client-spa-public-pkce_uri=http%3A%2F%2Flocalhost%2F_mode=fragment_type=code=openid
>
> Authorization Response:
>
> http://127.0.0.1/#session_state=46556363-c53f-489f-871c-58d376a8f9c1=2b84ee14-68ff-48c9-b480-4349ff9805f7.46556363-c53f-489f-871c-58d376a8f9c1.6fab0727-6184-47ad-8607-55f19896e945
>
> Token Request:
>
> POST /auth/realms/XXX/protocol/openid-connect/token HTTP/1.1
> Host: identity-provider:8080
> Content-type: application/x-www-form-urlencoded
>
> code=2b84ee14-68ff-48c9-b480-4349ff9805f7.46556363-c53f-489f-871c-58d376a8f9c1.6fab0727-6184-47ad-8607-55f19896e945_type=authorization_code_id=client-spa-public-pkce_uri=http%3A%2F%2Flocalhost%2F_verifier=IqiCQGM06JEyW73AB3f3oblCQKHOorapyqHUcYRujuSikDJx8cvBQ0kmFmzW75uIfaSBtXQrRmwuk71WWO6ryCzahTcxBPYX
>
> As a result, an access token was issued although the code_verifier provided 
> in the token request did not match the code_challenge and 
> code_challenge_method in the authorization request as they were absent.
>
> An attacker can thus send the victim the authorization response, after the 
> victim clicks the link, the client application sends a Token Request with the 
> code_verifier present with the client to Keycloak.
>
> As a result, a token is issued for the application, although the 
> code_verifier does not match the inexistent 
> code_challenge/code_challenge_method in the malicious authorization response.
>
> For this to work, the client must either generate a code_verifier on the fly 
> or have one already present. This obviously depends on the precise 
> implementation of the respective client.
>
> To reach such a state, an attacker could trick the user into starting the 
> authorization grant but clicking the malicious link before the authorization 
> response is sent.
>
> Best Regards,
>
> Benjamin Häublein
> Senior Consultant
>
> cirosec GmbH
> Ferdinand-Braun-Strasse 4
> 74074 Heilbronn
> Germany
> Phone: +49 (7131) 59455-74
> Fax: +49 (7131) 59455-99
> Mobile: +49 (151) 122414-74www.cirosec.de
>
> HRB Stuttgart 107883
> CEO Stefan Strobel, CFO Peter Lips
>
> Von: Warren Parad 
> Gesendet: Mittwoch, 5. Januar 2022 13:44
> An: Benjamin Häublein 
> Cc: George Fletcher ; oauth@ietf.org
> Betreff: Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier 
> facilitates Login-CSRF
>
> Sie erhalten nicht oft E-Mail von "wpa...@rhosys.ch". [Weitere Informationen, 
> warum dies wichtig ist](http://aka.ms/LearnAboutSenderIdentification)
>
> I'm not following to be honest. Could you detail concretely what the flow 
> would be that would result in vulnerability?
>
> Warren Parad
>
> Founder, CTO
>
> Secure your user data with IAM authorization as a service. Implement 
> [Authress](https://authress.io/).
>
> On Wed, Jan 5, 2022 at 1:41 PM Benjamin Häublein 
>  wrote:
>
>> Finally, I'm not sure a client that doesn't send the 'code_challenge' and 
>> 'code_challenge_method' on the authorization request but does send the 
>> 'code_verifier' on the token request should consider that the client has 
>> implemented PKCE correctly and hence can rely on it for CSRF.
>>
>> My point is not, that a client behaves that way. The problem is that an 
>> attacker could get a user (through social engineering) to start the 
>> authorization process and then click a link with an authorization response 
>> that the attacker provides.
>>
>> Then the client has send the 'code_challenge' and 'code_challenge_method' in 
>> the authorization request, but the authorization response belongs to an 
>> authorization request that does not have these parameters.
>>
>> When the client sends the token request based on the malicious authorization 
>> request but with the ‘code_verifier’ for the original authorization request.
>>
>> When the AS behaves as described the client has no way to know that an 
>> attacker has interfered.
>>
>> Best Regards,
>>
>> Benjamin Häublein
>>
>> Von: George Fletcher 
>> Gesendet: Dienstag, 4. Januar 2022 14:51
>> An: Benjamin Häublein ; oauth@ietf.org
>> Betreff: Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier 
>> facilitates Login-CSRF
>>
>> My guess is that for an Authorization Server that doesn't receive a 
>> 'code_challenge' and 'code_challenge_method' as part of the authorization 
>> request, they treat the request as a non-PKCE authorization request. 
>> Therefore when the 'code_verifier' is presented at the /token endpoint, the 
>> AS ignores the parameter because it doesn't consider the request to be a 
>> PKCE request. I can also see the AS returning an 

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

[Benjamin Häublein]

The following example shows this behavior in keycloak:
Authorization Request:
http://identity-provider:8080/auth/realms/XXX/protocol/openid-connect/auth?client_id=client-spa-public-pkce_uri=http%3A%2F%2Flocalhost%2F_mode=fragment_type=code=openid
Authorization Response:
http://127.0.0.1/#session_state=46556363-c53f-489f-871c-58d376a8f9c1=2b84ee14-68ff-48c9-b480-4349ff9805f7.46556363-c53f-489f-871c-58d376a8f9c1.6fab0727-6184-47ad-8607-55f19896e945
Token Request:
POST /auth/realms/XXX/protocol/openid-connect/token HTTP/1.1
Host: identity-provider:8080
Content-type: application/x-www-form-urlencoded

code=2b84ee14-68ff-48c9-b480-4349ff9805f7.46556363-c53f-489f-871c-58d376a8f9c1.6fab0727-6184-47ad-8607-55f19896e945_type=authorization_code_id=client-spa-public-pkce_uri=http%3A%2F%2Flocalhost%2F_verifier=IqiCQGM06JEyW73AB3f3oblCQKHOorapyqHUcYRujuSikDJx8cvBQ0kmFmzW75uIfaSBtXQrRmwuk71WWO6ryCzahTcxBPYX

As a result, an access token was issued although the code_verifier provided in 
the token request did not match the code_challenge and code_challenge_method in 
the authorization request as they were absent.

An attacker can thus send the victim the authorization response, after the 
victim clicks the link, the client application sends a Token Request with the 
code_verifier present with the client to Keycloak.
As a result, a token is issued for the application, although the code_verifier 
does not match the inexistent code_challenge/code_challenge_method in the 
malicious authorization response.

For this to work, the client must either generate a code_verifier on the fly or 
have one already present. This obviously depends on the precise implementation 
of the respective client.
To reach such a state, an attacker could trick the user into starting the 
authorization grant but clicking the malicious link before the authorization 
response is sent.

Best Regards,
Benjamin Häublein
Senior Consultant

cirosec GmbH
Ferdinand-Braun-Strasse 4
74074 Heilbronn
Germany
Phone: +49 (7131) 59455-74
Fax: +49 (7131) 59455-99
Mobile: +49 (151) 122414-74
www.cirosec.de

HRB Stuttgart 107883
CEO Stefan Strobel, CFO Peter Lips

Von: Warren Parad 
Gesendet: Mittwoch, 5. Januar 2022 13:44
An: Benjamin Häublein 
Cc: George Fletcher ; oauth@ietf.org
Betreff: Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier 
facilitates Login-CSRF

Sie erhalten nicht oft E-Mail von "wpa...@rhosys.ch". 
Weitere Informationen, warum dies wichtig 
ist
I'm not following to be honest. Could you detail concretely what the flow would 
be that would result in vulnerability?


[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

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


On Wed, Jan 5, 2022 at 1:41 PM Benjamin Häublein 
mailto:benjamin.haeubl...@cirosec.de>> wrote:
Finally, I'm not sure a client that doesn't send the 'code_challenge' and 
'code_challenge_method' on the authorization request but does send the 
'code_verifier' on the token request should consider that the client has 
implemented PKCE correctly and hence can rely on it for CSRF.
My point is not, that a client behaves that way. The problem is that an 
attacker could get a user (through social engineering) to start the 
authorization process and then click a link with an authorization response that 
the attacker provides.
Then the client has send the 'code_challenge' and 'code_challenge_method' in 
the authorization request, but the authorization response belongs to an 
authorization request that does not have these parameters.
When the client sends the token request based on the malicious authorization 
request but with the ‘code_verifier’ for the original authorization request.
When the AS behaves as described the client has no way to know that an attacker 
has interfered.

Best Regards,
Benjamin Häublein
Von: George Fletcher mailto:gffle...@aol.com>>
Gesendet: Dienstag, 4. Januar 2022 14:51
An: Benjamin Häublein 
mailto:benjamin.haeubl...@cirosec.de>>; 
oauth@ietf.org
Betreff: Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier 
facilitates Login-CSRF

My guess is that for an Authorization Server that doesn't receive a 
'code_challenge' and 'code_challenge_method' as part of the authorization 
request, they treat the request as a non-PKCE authorization request. Therefore 
when the 'code_verifier' is presented at the /token endpoint, the AS ignores 
the parameter because it doesn't consider the request to be a PKCE request. I 
can also see the AS returning an error regarding an "unexpected parameter" or 
"invalid request" error in this case.

I agree with your recommendation for the AS to require specific clients to use 
PKCE and consider an authorization request 

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

[Warren Parad]

I'm not following to be honest. Could you detail concretely what the flow
would be that would result in vulnerability?

Warren Parad

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


On Wed, Jan 5, 2022 at 1:41 PM Benjamin Häublein <
benjamin.haeubl...@cirosec.de> wrote:

> Finally, I'm not sure a client that doesn't send the 'code_challenge' and
> 'code_challenge_method' on the authorization request but does send the
> 'code_verifier' on the token request should consider that the client has
> implemented PKCE correctly and hence can rely on it for CSRF.
>
> My point is not, that a client behaves that way. The problem is that an
> attacker could get a user (through social engineering) to start the
> authorization process and then click a link with an authorization response
> that the attacker provides.
>
> Then the client has send the 'code_challenge' and 'code_challenge_method'
> in the authorization request, but the authorization response belongs to an
> authorization request that does not have these parameters.
>
> When the client sends the token request based on the malicious
> authorization request but with the ‘code_verifier’ for the original
> authorization request.
>
> When the AS behaves as described the client has no way to know that an
> attacker has interfered.
>
>
>
> Best Regards,
>
> Benjamin Häublein
>
> *Von:* George Fletcher 
> *Gesendet:* Dienstag, 4. Januar 2022 14:51
> *An:* Benjamin Häublein ; oauth@ietf.org
> *Betreff:* Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies
> code_verifier facilitates Login-CSRF
>
>
>
> My guess is that for an Authorization Server that doesn't receive a
> 'code_challenge' and 'code_challenge_method' as part of the authorization
> request, they treat the request as a non-PKCE authorization request. Therefore
> when the 'code_verifier' is presented at the /token endpoint, the AS
> ignores the parameter because it doesn't consider the request to be a PKCE
> request. I can also see the AS returning an error regarding an "unexpected
> parameter" or "invalid request" error in this case.
>
> I agree with your recommendation for the AS to require specific clients to
> use PKCE and consider an authorization request without PKCE to be an error.
>
> Finally, I'm not sure a client that doesn't send the 'code_challenge' and
> 'code_challenge_method' on the authorization request but does send the
> 'code_verifier' on the token request should consider that the client has
> implemented PKCE correctly and hence can rely on it for CSRF.
>
> Thanks,
> George
>
> On 1/4/22 5:45 AM, Benjamin Häublein wrote:
>
> Hello everyone,
>
> I think RFC 7636 “Proof Key for Code Exchange by OAuth Public Clients”,
> section 4.6. “Server Verifies code_verifier before Returning the Tokens”
> leaves a tiny gap regarding the handling of verification when no code
> challenge was present in the authorization request:
>
>Upon receipt of the request at the token endpoint, the server
>
>verifies it by calculating the code challenge from the received
>
>"code_verifier" and comparing it with the previously associated
>
>"code_challenge", after first transforming it according to the
>
>"code_challenge_method" method specified by the client.
>
> It is unspecified how the server should behave when “code_verifier” is
> present, but “code_challenge” and “code_challenge_method” were not set in
> the initial authorization request.
>
> The following example worked for three well-known authorization servers
> where the client was configured in a way that PKCE could be used, but was
> not enforced:
>
> Authorization Request:
>
>
> https:///auth?client_id=_type=code=openid+profile_uri=https://localhost
>
> Subsequent Token Request:
>
> POST /token HTTP/1.1
> Host: 
> Content-Length: 256
>
>
> code=_type=authorization_code_id=_uri=https%3A%2F%2Flocalhost_verifier=IqiCQGM06JEyW73AB3f3oblCQKHOorapyqHUcYRujuSikDJx8cvBQ0kmFmzW75uIfaSBtXQrRmwuk71WWO6ryCzahTcxBPYX
>
> As a result, an access token was issued although the code_verifier
> provided in the token request did not match the code_challenge and
> code_challenge_method in the authorization request.
>
>
>
> Many applications consider the usage of PKCE as enough protection from
> Login-CSRF and do not use state or nonce (for example this blog entry by
> Daniel Fett
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/
> suggests, that neither state nor nonce are necessary when PKCE is used).
> However, when the authorization server is not configured to require a
> specific code_challenge_method from the client and the authorization
> behaves as described in the example, PKCE does not protect from Login-CSRF.
>
> I think the following mitigations are possible:
>
>1. Enforce usage of PKCE in the client configuration in the
>Authorization Server
>2. Implementation of the authorization server returns an error in the
>Access 

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

[Benjamin Häublein]

Finally, I'm not sure a client that doesn't send the 'code_challenge' and 
'code_challenge_method' on the authorization request but does send the 
'code_verifier' on the token request should consider that the client has 
implemented PKCE correctly and hence can rely on it for CSRF.
My point is not, that a client behaves that way. The problem is that an 
attacker could get a user (through social engineering) to start the 
authorization process and then click a link with an authorization response that 
the attacker provides.
Then the client has send the 'code_challenge' and 'code_challenge_method' in 
the authorization request, but the authorization response belongs to an 
authorization request that does not have these parameters.
When the client sends the token request based on the malicious authorization 
request but with the ‘code_verifier’ for the original authorization request.
When the AS behaves as described the client has no way to know that an attacker 
has interfered.

Best Regards,
Benjamin Häublein

Von: George Fletcher 
Gesendet: Dienstag, 4. Januar 2022 14:51
An: Benjamin Häublein ; oauth@ietf.org
Betreff: Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier 
facilitates Login-CSRF

My guess is that for an Authorization Server that doesn't receive a 
'code_challenge' and 'code_challenge_method' as part of the authorization 
request, they treat the request as a non-PKCE authorization request. Therefore 
when the 'code_verifier' is presented at the /token endpoint, the AS ignores 
the parameter because it doesn't consider the request to be a PKCE request. I 
can also see the AS returning an error regarding an "unexpected parameter" or 
"invalid request" error in this case.

I agree with your recommendation for the AS to require specific clients to use 
PKCE and consider an authorization request without PKCE to be an error.

Finally, I'm not sure a client that doesn't send the 'code_challenge' and 
'code_challenge_method' on the authorization request but does send the 
'code_verifier' on the token request should consider that the client has 
implemented PKCE correctly and hence can rely on it for CSRF.

Thanks,
George

On 1/4/22 5:45 AM, Benjamin Häublein wrote:
Hello everyone,
I think RFC 7636 “Proof Key for Code Exchange by OAuth Public Clients”, section 
4.6. “Server Verifies code_verifier before Returning the Tokens” leaves a tiny 
gap regarding the handling of verification when no code challenge was present 
in the authorization request:
   Upon receipt of the request at the token endpoint, the server
   verifies it by calculating the code challenge from the received
   "code_verifier" and comparing it with the previously associated
   "code_challenge", after first transforming it according to the
   "code_challenge_method" method specified by the client.
It is unspecified how the server should behave when “code_verifier” is present, 
but “code_challenge” and “code_challenge_method” were not set in the initial 
authorization request.
The following example worked for three well-known authorization servers where 
the client was configured in a way that PKCE could be used, but was not 
enforced:
Authorization Request:
https:///auth?client_id=_type=code=openid+profile_uri=https://localhost
Subsequent Token Request:
POST /token HTTP/1.1
Host: 
Content-Length: 256

code=_type=authorization_code_id=_uri=https%3A%2F%2Flocalhost_verifier=IqiCQGM06JEyW73AB3f3oblCQKHOorapyqHUcYRujuSikDJx8cvBQ0kmFmzW75uIfaSBtXQrRmwuk71WWO6ryCzahTcxBPYX
As a result, an access token was issued although the code_verifier provided in 
the token request did not match the code_challenge and code_challenge_method in 
the authorization request.

Many applications consider the usage of PKCE as enough protection from 
Login-CSRF and do not use state or nonce (for example this blog entry by Daniel 
Fett https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ 
suggests, that neither state nor nonce are necessary when PKCE is used). 
However, when the authorization server is not configured to require a specific 
code_challenge_method from the client and the authorization behaves as 
described in the example, PKCE does not protect from Login-CSRF.
I think the following mitigations are possible:

  1.  Enforce usage of PKCE in the client configuration in the Authorization 
Server
  2.  Implementation of the authorization server returns an error in the Access 
Token Response when code_verifier is present in the token request, but no 
code_challenge and code_challenge_method is present in the authorization 
request.
  3.  Additionally, when the behavior of an AS is correct (verification of 
code_verifier fails when no code_challenge was present), a client that relies 
on PKCE for CSRF protection must always include a code_verifier parameter in 
the token request (even if no code_verifier is present on the client side).

Best regards,

Benjamin Häublein
Senior Consultant

cirosec GmbH

[OAUTH-WG] [Editorial Errata Reported] RFC8707 (6810)

[RFC Errata System]

The following errata report has been submitted for RFC8707,
"Resource Indicators for OAuth 2.0".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6810

--
Type: Editorial
Reported by: Jan Goebel 

Section: 4

Original Text
-
In typical OAuth deployments the authorization sever is in a position
to observe and track a significant amount of user and client behavior.

Corrected Text
--
In typical OAuth deployments, the authorization server is in a position
to observe and track a significant amount of user and client behavior.

Notes
-
1. typo: sever -> server
2. I think we also need a comma after "In typical OAuth deployments" because it 
is an introductory phrase, but maybe a native English speaker can confirm.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8707 (draft-ietf-oauth-resource-indicators-08)
--
Title   : Resource Indicators for OAuth 2.0
Publication Date: February 2020
Author(s)   : B. Campbell, J. Bradley, H. Tschofenig
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

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

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

[Daniel Fett]

Hi Benjamin,

thanks for bringing this up!

What you describe is essentially a downgrade from PKCE to a non-PKCE flow.

Nov Matake pointed out this possibility in an earlier discussion:
https://mailarchive.ietf.org/arch/msg/oauth/qrLAf3nWRt8HAFkO49qGrPRuelo/

We therefore added this attack to the Security BCP:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-19#page-28

As countermeasures, the BCP lists

   Beyond this, to prevent PKCE downgrade attacks, the AS MUST ensure
   that if there was no code_challenge in the authorization request, a
   request to the token endpoint containing a code_verifier is rejected.

   Note: AS that mandate the use of PKCE in general or for particular
   clients implicitly implement this security measure.

-Daniel



Am 04.01.22 um 11:45 schrieb Benjamin Häublein:
>
> Hello everyone,
>
> I think RFC 7636 “Proof Key for Code Exchange by OAuth Public
> Clients”, section 4.6. “Server Verifies code_verifier before Returning
> the Tokens” leaves a tiny gap regarding the handling of verification
> when no code challenge was present in the authorization request:
>
>    Upon receipt of the request at the token endpoint, the server
>
>    verifies it by calculating the code challenge from the received
>
>    "code_verifier" and comparing it with the previously associated
>
>    "code_challenge", after first transforming it according to the
>
>    "code_challenge_method" method specified by the client.
>
> It is unspecified how the server should behave when “code_verifier” is
> present, but “code_challenge” and “code_challenge_method” were not set
> in the initial authorization request.
>
> The following example worked for three well-known authorization
> servers where the client was configured in a way that PKCE could be
> used, but was not enforced:
>
> Authorization Request:
>
> https:///auth?client_id=_type=code=openid+profile_uri=https://localhost
> 
>
> Subsequent Token Request:
>
> POST /token HTTP/1.1
> Host: 
> Content-Length: 256
>
> code=_type=authorization_code_id=_uri=https%3A%2F%2Flocalhost_verifier=IqiCQGM06JEyW73AB3f3oblCQKHOorapyqHUcYRujuSikDJx8cvBQ0kmFmzW75uIfaSBtXQrRmwuk71WWO6ryCzahTcxBPYX
>
> As a result, an access token was issued although the code_verifier
> provided in the token request did not match the code_challenge and
> code_challenge_method in the authorization request.
>
>  
>
> Many applications consider the usage of PKCE as enough protection from
> Login-CSRF and do not use state or nonce (for example this blog entry
> by Daniel Fett
> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/
> 
> suggests, that neither state nor nonce are necessary when PKCE is
> used). However, when the authorization server is not configured to
> require a specific code_challenge_method from the client and the
> authorization behaves as described in the example, PKCE does not
> protect from Login-CSRF.
>
> I think the following mitigations are possible:
>
>   * Enforce usage of PKCE in the client configuration in the
> Authorization Server
>   * Implementation of the authorization server returns an error in the
> Access Token Response when code_verifier is present in the token
> request, but no code_challenge and code_challenge_method is
> present in the authorization request.
>   * Additionally, when the behavior of an AS is correct (verification
> of code_verifier fails when no code_challenge was present), a
> client that relies on PKCE for CSRF protection must always include
> a code_verifier parameter in the token request (even if no
> code_verifier is present on the client side).
>
>  
>
> Best regards,
>
>  
>
> Benjamin Häublein
> Senior Consultant
>
> cirosec GmbH
> Ferdinand-Braun-Strasse 4
> 74074 Heilbronn
> Germany
> Phone: +49 (7131) 59455-74
> Fax: +49 (7131) 59455-99
> Mobile: +49 (151) 122414-74
> www.cirosec.de
>
> HRB Stuttgart 107883
> CEO Stefan Strobel, CFO Peter Lips
>
>  
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de

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