OAuth authorization server comparison

[hickford]

A comparison of features in various OAuth authorization servers

	GitHub	GitLab	BitBucket	Gitea	Google	Azure DevOps	SourceHut
Records client type at registration	❌	✓	✓	✓	✓	❌	❌
Supports PKCE	❌	✓	❌	✓	✓	❌
Enforces PKCE for public clients	❌	❌	❌	✓	❌	❌
User consent for every public client authorization	❌	❌	❌	❌	✓	❌
Access token expiry	❌	✓	✓	✓	✓	✓
Refresh tokens	❌	✓	✓	✓	✓	✓
Refresh tokens are single use	❌	✓	❌	❌	❌	❌
Public client authentication without secret	❌	✓	❌	✓	❌	✓
Device authorization grant	✓	❌	❌	❌	✓	❌
Basic auth username	Any	oauth2	x-token-auth	Any	Any
Bearer auth	❌	❌	✓	✓	✓

Details

1. Record client type at registration:

   The client type designation is based on the authorization server's definition of secure authentication and its acceptable exposure levels of client credentials. The authorization server SHOULD NOT make assumptions about the client type.

2. Supports PKCE

   Authorization servers MUST support PKCE

3. Enforces PKCE for public clients

   [Authorization server] MUST reject requests without a code_challenge from public clients

4. User consent for every public client authorization

   the authorization server SHOULD NOT process authorization requests automatically without user consent or interaction, except when the identity of the client can be assured. This includes the case where the user has previously approved an authorization request for a given client id

5. Access token expiry

   Authorization servers SHOULD issue short-lived bearer tokens, particularly when issuing tokens to clients that run within a web browser or other environments where information leakage may occur. Using short-lived bearer tokens can reduce the impact of them being leaked.

6. Refresh tokens

   Refresh tokens also add to the security of OAuth, since they allow the authorization server to issue access tokens with a short lifetime and reduced scope, thus reducing the potential impact of access token leakage.

7. Refresh tokens are single use:

   Refresh tokens for public clients MUST be sender-constrained or use refresh token rotation

8. Public client authentication without secret

   it is NOT RECOMMENDED for authorization servers to require client authentication of public native apps clients using a shared secret

[hickford]

Records client type at registration

Screenshots of OAuth client registration https://imgur.com/a/GADt0MO

[bgavrilMS]

For Azure DevOps, the identity provide is Azure Active Directory. It supports PKCE.

Refresh tokens are not single use, AAD is going with a more advanced approach here - https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-token-protection

[adam-azarchs]

GitHub supports refresh tokens. It just doesn't require them.

[hickford]

GitHub supports refresh tokens. It just doesn't require them.

@adam-azarchs Your link appears to relate to a different API called GitHub Apps. The OAuth API that I tested is https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps . No refresh tokens are issued.

[hickford]

For Azure DevOps, the identity provide is Azure Active Directory. It supports PKCE.

Refresh tokens are not single use, AAD is going with a more advanced approach here - https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-token-protection

@bgavrilMS I think we're discussing different APIs. The OAuth API that I tested is Azure DevOps Services https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/oauth?view=azure-devops (PKCE challenge ignored)

Cool feature though 😎 sender-constrained tokens