Questions[oauth](server)

I need to cURL a web app hosted behind IAP on GCP.

Normally, users log in through IAP and use the web app, but I need to run some cURL commands (interactive and non-interactive) that hit the web app URLs (for example: https://myapp.com/get_pics/1)

I cannot figure out how to get a Bearer token from GCP that I can use in the authorization header for cURL.

I can set up a service account with "IAP Secured Web App User" role and I have the JSON key for this service account, but I am not sure where to go after that to get a proper Bearer token that IAP will accept.

Message in the consent screen settings:

Comply with domain verification requirements Ensure your application's domains have completed the Search Console verification process

But... all my domains on the search console have been verified. What can I do?

I have a Node.js/Express web app running on the Google Cloud Platform App Engine.

I'm restricting access to this application using the Identity Aware Proxy (IAP), so that only people in my company can access the website when they are logged on to Google using their corporate accounts.

This works great, only one thing annoys me:

For the OAuth 2 client that restricts the access, I have configured the URL of a privacy and data policy page which is linked from the Google login form that is shown to users when they try to access the website.

This privacy page is also served by my web application, so when people who are not yet logged in click on the link presented on the login form, they are asked to log in to view the privacy page, since all my web app's pages are protected by the IAP. A chicken-and-egg type of problem.

Is there a way to exclude specific URLs from the IAP and allow access without logging in?

We have a Windows 2016 ADFS 4.0 farm (WID database, not SQL Server) hosted in Azure.

We are working with a new OpenID Connect application, and want to use ADFS to authenticate and populate user profiles from AD. The application is using a shared secret for the JWT config.

This was very easy to configure in our Test environment (single node farm).

When we configured the same application server on our production ADFS server, we were initially successful, but after logging in, we started to intermittently get login errors. After you log in to ADFS, you are sent to the callback URL. This redirects you to a login page, and on that page is a modal dialog box with this error message: Call to IdP failed to get identity

If we hit refresh a few times, eventually, the application will allow us into the application. When we ran a fiddler trace on the bad connection, we found this error:

{"errorCodeString":"camAuthUnrecoverable",
"messages":[{"messageString":"Call to IdP failed to get identity. Status 400\nError: invalid_grant\nError description: MSIS9612: The authorization code received in 'code' parameter is invalid. "}],
"promptInfo":{"captions":["Call to IdP failed to get identity"]}}

I found errors in ADFS event viewer with this sort of message:

Encountered error during OAuth token request. 

Additional Data 

Exception details: 
    Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthAccessTokenInvalidAuthorizationCodeException: 
MSIS9252: The authorization code received is invalid. 
No artifact found for the specified authorization code: '//redacted//'. 
The cause may be that artifact has timed out, or the authorization code was replayed, or the authorization code is invalid. 
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthTokenProtocolHandler.RedeemAccessToken(OAuthAccessTokenRequestContext tokenContext)

In every case we were able to log in after we hit reload a number of times.

When we reduced the number of nodes in the farm to 1, the issue appeared to disappear, and reappeared when we re-added the nodes.

Have others run into this issue when setting up openid connect/oAuth2 apps? How did you resolve this?

While SAML2 artifact resolution is not supported in ADFS 4.0 using WID, there isn't anything saying the same issue applies to OpenID Connect, although it's my only guess as to the issue. Is it worth the expense to convert ADFS to use a SQL Server cluster?

In the OAuth2 authentication process refresh tokens should be used only once. When the refresh_token is used it will return a new access_token and a new refresh_token.

This is also in the RFC6819 spec:

5.2.2.3. Refresh Token Rotation

Refresh token rotation is intended to automatically detect and prevent attempts to use the same refresh token in parallel from different apps/devices. This happens if a token gets stolen from the client and is subsequently used by both the attacker and the legitimate client. The basic idea is to change the refresh token value with every refresh request in order to detect attempts to obtain access tokens using old refresh tokens. Since the authorization server cannot determine whether the attacker or the legitimate client is trying to access, in case of such an access attempt the valid refresh token and the access authorization associated with it are both revoked.

The OAuth specification supports this measure in that the token's response allows the authorization server to return a new refresh token even for requests with grant type "refresh_token".

Note: This measure may cause problems in clustered environments, since usage of the currently valid refresh token must be ensured. In such an environment, other measures might be more appropriate.

This also allows the authentication server to recognize that a refresh_token was compromised, since it should only be used once. If a new renew request with the same refresh_token comes in the authentication server knows there is something fishy going on.

I wonder what is the proper way for the server to deal with such a scenario though? My guess would be that at least all the access_tokens for that particular client should be invalidated directly.

How do OAuth2 servers usually deal with multiple requests using the same refresh_token?