Should this http://www.playframework.com/documentation/2.0/ScalaOAuth be included?

For OAuth with grant_type = authorization_code is it possible to display "OAuth approval" screen only once for a user?
Or any other way to make it auto approval?

Should this https://github.com/go-oauth2/oauth2 be include?

The site links to the last draft but no obvious link to rfc6749.

Please add RSS feed for at least new OAuth 2 specs. openid.net site has one, so it would be convenient to track news about OAuth/OIDC in a single tracker.

From: https://github.com/lncd/OAuth2 (there's a link to a new repo)
To: https://github.com/php-loep/oauth2-server

I think there should be some explanation on this sentence in https://github.com/aaronpk/oauth.net/blob/main/public/id-tokens-vs-access-tokens/index.php as this is used as a source for a lot of online discussions.

ID tokens should never be sent to an API. Access tokens should never be read by the client.

I think there should at least be an explanation on the difference in the 3rd party case (e.g. app X wants to use your Y account in to perform scopes Z - in this case the sentence makes a lot of sense) vs the 1st party case (e.g. an SPA with a stateless e.g. serverless backend, which is being used a lot de-facto, in which the client must have access to either access or id tokens to make XHR calls with an authorization header*)

For more context on the confusion this causes (at least to me), please see my rant comment here: auth0/auth0-spa-js#54 (comment)

As it stands now, unless I don't understand the interpretation of client, any SPA out there that sends XHR calls with an Authorization header (even with an access token because they bothered reading the first half of the sentence) will violate the second half.

In addition, Google does recommend sending ID tokens https://developers.google.com/identity/sign-in/web/backend-auth
Also AWS API Gateway also allows Cognito ID Tokens.

Since the two of the 3 largest cloud providers allow ID tokens for "your frontend accessing your backend first party use case" (violating the first half), and a lot of "stateless" SPAs out there have to let you read the access token to add an authorization header when making backend calls, I think an explanation on either why it's still bad or why it's sometimes ok (de jure vs de facto) will help people make better educated decisions.

I'll be happy to suggest a pull request with clarifications but before I do I want to make sure I understand it enough to be able to explain it correctly.

_{* as the alternative of storing an httpOnly cookie with the JWT, which is not possible unless the backend is same origin, and if you send a JS readable cookie might as well store it in sessionStorage / localStorage, let's put aside the XSRF vs XSS tradeoff argument}

On page http://oauth.net/2/, the given python server implementation (https://github.com/StartTheShift/pyoauth2) is no longer maintained. An up-to-date project seems to be https://github.com/NateFerrero/oauth2lib.

hi @AArnott , I developed a Oauth2 and OpenId connect system, I Like to listed in https://oauth.net/code/ page. what is the procedure for that?

Can we add a functionality to export this website to PDF? If @aaronpk is alright with this, I can attempt a PR.

https://oauth.net/2/grant-types/authorization-code/ is the Authorization Code Grant, not a specific Flow.
But it says:

It is recommended that all clients use the PKCE extension with this flow as well to provide better security.

This information also isn't true? If you have a private client where the client secret is only known to the resource server having PKCE doesn't make sense?!

Hi,

in many large enterprises, there is the need to pass the end user identity when doing a system to system communication. Example: One system B is updated by another system A (by calling an API). The information about the end user that typed in data in system A should be passed along when System A calls B.

I didnt find information that describes how that is can be done with OAuth2.

My idea is to use client credentials grant and then pass a user identifier along. That user identifier is then picked up at the API Gateway and using OIDC, the full user info is added to the upstream calls.

Questions at all and @aaronpk

1. Is my idea any good. What is a good way of passing the user identifier (where, how)
2. if not, what is the recommended way

Thanks a lot

P.S Happy to compile all the answers and update the page

According to https://www.oauth.com/oauth2-servers/access-tokens/access-token-response/

Error responses are returned with an HTTP 400 status code (unless
specified otherwise), with error and error_description parameters. The
error parameter will always be one of the values listed below.

• invalid_request
• invalid_client
• invalid_grant
• invalid_scope
• unauthorized_client
• unsupported_grant_type

Can I have custom error like "invalid_captcha" or "captcha_required"?

I want , if some one send wrong credentials for 3 times , I send "captcha_required" error and for next time must send valid captcha code

My question is:

1. Is it allowed to define custom error codes in OAuth ?
2. Is there alternative way to solve my problem?

The link to OAuth 2.1 spec on Specs page is broken. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1 results in a 404. As the same formatted link to the security BCP works, I suspect this may be a bug on the IETF’s site – maybe their page interprets the -1 as version identifier?

Another thing I noticed: The pages title is "Code". A copy ’n’ paste error?

BTW: Thanks for maintaining oauth.net!

@fkooman I just noticed your server is linked from http://oauth.net/2/ and points to a demo URL that no longer works. Do you have that running at a new location? See https://github.com/aaronpk/oauth.net/blob/master/2/index.php#L49

This feels like a small mistake made by using the wrong tool before dragging the object, or accidentally dragging it, while leaving some anchors behind. IMO it's pretty obvious, even in a smaller non-zoomed size as an asset placed anywhere. I can't stop noticing it. 😂

I think you could add it to the list
https://code.google.com/p/oauth-php/

Hi there--am wondering if it's okay to create a new section for middleware and add my colleagues' Gin project. As noted in the README, "Gin-OAuth2 is specially made for Gin Framework users who also want to use OAuth2. It was created by Go developers who needed Gin middleware for working with OAuth2 and couldn't find any." Thanks!

https://oauth.net/getting-started/
In the "OAuth 2.0 Servers" subsection a link:
OAuth 2.0 Clients = https://oauth.com/oauth2-servers/oauth2-clients/
Error 404, fyi!

Cheers
Peter
[email protected]

I suggest adding a link to this book from 2022 https://link.springer.com/book/10.1007/978-1-4842-8261-8

hI ,

I have a Authorization Server (Thinktecture) which supports oauth channel and I want to get the token from the Authorization Server . Should I use only that oauth client provided by my I Authorization Server (Thinktecture) or I can use any oauth 2 client .

Suppose if i am using Thinktecture Authorization Server to get a token to my Java application . can i use native java Oauth client (Apache Amber , Srcibe) to talk to Authorization Server ?

first time opening

In this article, there is a link called non-chocolate fudge which links to a fudge recipe requiring chocolate. It could be confusing or misleading. Some people think there is no such thing as fudge that doesn't contain chocolate and this might reinforce that idea.

When clicking on the 'Token Introspection Endpoint' link in the token revocation webpage (https://oauth.net/2/token-revocation/), it navigates to the 'Token Introspection Endpoint' webpage(https://www.oauth.com/oauth2-servers/token-introspection-endpoint/).

I think it would be cool if there was a separation between open source projects (like Keycloak, ORY Hydra) that support OAuth2, and proprietary systems at https://oauth.net/code/

For the latter (proprietary) we could do a separation between self-hosted (e.g. FusionAuth) and managed (e.g. Okta).

That would probably help to quickly decide what to use as a user when visiting that site!

https://oauth.net/2/oauth-best-practice/

Initial list given in the slides in IETF 106

Hello, technical engineers, I would like to consult about the Oauth certification process. The redirect_uri request parameter in the certification URL will trigger the security product rules and cause the request to be intercepted. The triggered security rule is: "Server-Side Request Forgery", for details The parameter is caused by redirect_uri, is there any solution? For example, can the parameter redirect_uri in the URL be changed to another name, because the security product recognizes that the normal request caused by the redirect_uri is intercepted, and the attached image is the detailed data packet that was intercepted when the request was initiated. If you can reply, I am very grateful.

I believe that the deprecation of the Password Grant flow leaves a gap in situations where a third-party client needs to authenticate with an API with a specific user account which is different to the user account of the end user on the client.

The primary reason for the deprecation of Password Grant is that the users' credentials are exposed to the client. However, where the end user is authenticated with the client application as a user internal to the client and the client authenticates as a user within the scope of the API using it's own credentials, there is no issue with the credentials being handled by the client.
In this situation the recommended Auth Code flow is not appropriate because it requires the logged in user to consent to the authentication which requires a manual interaction in the browser.
In the case of the Password Grant flow, the client can authenticate with the API without manual interaction.

Assuming the client is a server-side application with the credentials obscured from the end user, I see no reason why Password Grant is not appropriate. Otherwise, what is the appropriate alternative that enables a client to automatically authenticate with a client without user interaction but scoped to a particular user account?

Hi @aaronpk

Thanks for a well maintained resource.

If I may, I would like to get your feedback on what is my interpretation of https://tools.ietf.org/html/rfc6749#section-4.4 and if it warrants an update to https://oauth.net/2/grant-types/client-credentials/.

Most resources I find online are generally quite "strict" in stating how the concept of a user has no place in the context of
the client_credentials grant. I believe this is incorrect or at the very least, misleading.

From https://tools.ietf.org/html/rfc6749#section-4.4, (emphasis mine):

The client can request an access token using only its client
credentials (or other supported means of authentication) when the
client is requesting access to the protected resources under its
control, or those of another resource owner that have been previously
arranged with the authorization server (the method of which is beyond
the scope of this specification).

"Another resource owner" can very well be a user, that through some application-specific business rules grants access to a client.

I would argue that a user wanting to access their own resources programatically is a common scenario, even if typically for more "tech-inclined users". This scenario in my opinion is perfectly suited for client_credentials and it seems unnecessary to "consider" the use of the password grant here (normally discouraged and not recommended by https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.4), due to the perception that the user context/concept is off-limits in client_credentials. Redirect-based flows are also not appropriate here.

From: https://oauth.net/2/grant-types/client-credentials/:

The Client Credentials grant type is used by clients to obtain an access token outside of the context of a user.

This is typically used by clients to access resources about themselves rather than to access a user's resources.

While the first sentence employs the rather strict "... is used... outside of the context of a user.", the use of "typically" in the second sentence allows some room for an interpretation closer to how the OAuth2 RFC defines clients_credentials.

I think it would benefit the understanding of the client_credentials grant if there was language alluding to the fact that it's a grant where access is granted without an authorization step (which IMHO is the big distinction between client_credentials and the redirection-based flows) rather than language that explicitly excludes the user context.

The seemingly explicit exclusion of the user context from most resources I find about client_credentials seems to have a disproportionate focus compared to what I interpret as the OAuth2 RFC stating as effectively application-specific - the resource owner being the client itself or some other entity, say, a user, and access/scope being "resolved" by some other means.

Any thoughts? :)

minor nitpicks for this page: https://www.oauth.com/oauth2-servers/access-tokens/self-encoded-access-tokens/
i'm aware this isn't the repo for oauth.com (not that it even has a repo) but anyway.

• smart quote in header json obj: "HS256”, and
• sub is a registered claim name with type StringOrURI, so don't think a number belongs there