Security, credentials, and OAuth-based authentication
Domain 6 - Security, credentials, and OAuth-based authentication
This domain tests access control, connection security, and token-based authentication. Expect questions on OAuth flows, scopes, credential storage, and protecting trigger endpoints.
Core rules
- OCI IAM controls who can access the service. Assign least-privilege service roles such as administrator, developer, monitor, and invoker; separate build and operate duties.
- Connection security policies include basic authentication, OAuth 2.0, OAuth 1.0, SAML, and SSL/TLS. The policy must match what the target endpoint expects.
- OAuth 2.0 client credentials is the usual choice for service-to-service calls with no user context. Authorization code is used when a user must consent and the call acts on that user's behalf. Resource owner password is legacy and should be avoided.
- Configure the token endpoint, client ID, client secret, and scopes on the connection. Request only the scopes the operation needs. Refresh tokens must be handled securely.
- REST trigger endpoints can be protected with an OAuth 2.0 policy that validates bearer tokens. Validate issuer, audience, and expiry; do not accept a token just because it is signed.
- Credentials belong in the credential store or a vault, not in mapping expressions or exported archives. Rotate secrets and update connections after rotation.
Worked example
An integration calls a SaaS API with no user interaction. Configure an OAuth 2.0 client-credentials connection: token URL, client ID, secret, and the required scope. Test the connection, then invoke it. If the API needs the end user's data, client credentials is wrong; use authorization code and propagate the user context.
Traps
Do not use the resource owner password flow for a new service integration. Do not request broad scopes. Do not hardcode secrets in XSLT or assignments. Do not assume an exported connection includes its password or client secret.