OAuth 2.0 Security Best Practice

OAuth 2.0 Security Best Practice highlights for IBM Security Verify Access OIDC Provider

It's essential to follow the best practices that are recommended by the OAuth 2.0 specification. The article highlights the key security recommendations for the IBM Security Verify Access OIDC Provider to help you ensure that it is security-enhanced.

Use the following enforcements to be compliant with OAuth 2.0 security best practices.

Avoid using the ROPC Flow

Resource Owner Password Credentials (ROPC) is not an OAuth 2.0 Security Best Practice. If you're currently using the ROPC flow, consider removing it from the configuration. To do so, remove the password entry from the grant_types section under Definition and Clients:
```
  grant_types:
    - authorization_code
    - implicit
    - password   // remove this entry
    - client_credentials
    - refresh_token
    - urn:openid:params:grant-type:ciba
```

Avoid using the Implicit Flow

To comply with OAuth 2.0 Security Best Practices, avoid the implicit flow because of security concerns.

In the grant types section under Definition and Clients, remove the entry of implicit.
```
  grant_types:
    - authorization_code
    - implicit   // remove this entry
    - client_credentials
    - refresh_token
    - urn:openid:params:grant-type:ciba
```

Authorization Code Grant (PKCE)

PKCE (Proof Key for Code Exchange) is a security feature for the authorization code grant flow in OAuth 2.0 that IBM Security Verify Access OIDC Provider supports. It must be used for public clients and is recommended for private clients.

In the Clients section, add the following entry.
```
  require_pkce: true
```
Learn more about Authorization Code with PKCE.

Certificate-bound or Mutual TLS sender-constrained tokens

Certificate-bound access tokens (sometimes also called Mutual TLS sender-constrained tokens) are bound to the underlying mutual TLS connection between the client and the authorization server. IBM Security Verify Access OIDC Provider supports both OAuth 2.0 Demonstration of Proof-of-Possession (DPoP) and Mutual TLS (MTLS). Use these features to enhance the security of your application.

Learn more about Sender Constrained Tokens

Client Authentication

Asymmetric (public-key based) methods for client authentication, such as Mutual TLS and Private Key JWT, are recommended as a part of OAuth 2.0 Security Best Practice, IBM Security Verify Access OIDC Provider supports both client authentication method.

End-to-End TLS

End-to-End TLS is an OAuth 2.0 security best practice. Use TLS to protect the communication between the point of contact (ISVA Web Reverse Proxy) and IBM Security Verify Access OIDC Provider.

In the Definition section, enable TLS for the Security Verify Access OIDC Provider.
```
  server:
    ssl:
      key: ks:server_keys/server_key
      certificate: ks:server_keys/server_cert    
```