You're viewing OCI IAM documentation for tenancies in regions that have not been updated to use identity domains.

Updated 2025-02-18

Managing User Credentials

This topic describes the basics of working with Oracle Cloud Infrastructure Identity and Access Management (IAM) user credentials. If you're not already familiar with the available credentials, see User Credentials.

Working with Console Passwords and API Keys

Each user automatically has the ability to change or reset their own Console password, as well as manage their own API keys. An administrator does not need to create a policy to give a user those abilities.
Note

Federated users might need to create a policy to modify API keys. For example, users who were provisioned through SCIM.

To manage credentials for users other than yourself, you must be in the Administrators group or some other group that has permission to work with the tenancy. Having permission to work with a compartment within the tenancy is not sufficient. For more information, see The Administrators Group and Policy.

IAM administrators (or anyone with permission to the tenancy) can use either the Console or the API to manage all aspects of both types of credentials, for themselves and all other users. This includes creating an initial one-time password for a new user, resetting a password, uploading API keys, and deleting API keys.

Users who are not administrators can manage their own credentials. In the Console, users can:

  • Change or reset their own password.
  • Upload an API key in the Console for their own use (and also delete their own API keys).

And with the API, users can:

  • Reset their own password with CreateOrResetUIPassword.
  • Upload an additional API key to the IAM service for their own use with UploadApiKey (and also delete their own API keys with DeleteApiKey). Remember that a user can't use the API to change or delete their own credentials until they themselves upload a key in the Console, or an administrator uploads a key for that user in the Console or the API.

A user can have a maximum of three API keys at a time.

Working with Auth Tokens

Note

"Auth tokens" were previously named "Swift passwords". Any Swift passwords you had created are now listed in the Console as auth tokens. You can continue to use the existing passwords.

Auth tokens are Oracle-generated token strings that you can use to authenticate with third-party APIs that do no support Oracle Cloud Infrastructure's signature-based authentication. Each user created in the IAM service automatically has the ability to create, update, and delete their own auth tokens in the Console or the API. An administrator does not need to create a policy to give a user those abilities. Administrators (or anyone with permission to the tenancy) also have the ability to manage auth tokens for other users.

Note that you cannot change your auth token to a string of your own choice. The token is always an Oracle-generated string.

Auth tokens do not expire. Each user can have up to two auth tokens at a time. To get an auth token in the Console, see To create an auth token.

Using an Auth Token with Swift

Swift is the OpenStack object store service. If you already have an existing Swift client, you can use it with the Recovery Manager (RMAN) to back up an Oracle Database System (DB System) database to Object Storage. You will need to get an auth token to use as your Swift password. When you sign in to your Swift client, you provide the following:

  • Your Oracle Cloud Infrastructure Console user login
  • Your Swift-specific auth token, provided by Oracle
  • Your organization's Oracle tenant name

Any user of a Swift client that integrates with Object Storage needs permission to work with the service. If you're not sure if you have permission, contact your administrator. For information about policies, see How Policies Work. For basic policies that enable use of Object Storage, see Common Policies.

Working with Customer Secret Keys

Note

"Customer Secret keys" were previously named "Amazon S3 Compatibility API keys". Any keys you had created are now listed in the Console as Customer Secret keys. You can continue to use the existing keys.

Object Storage provides an API to enable interoperability with Amazon S3. To use this Amazon S3 Compatibility API, you need to generate the signing key required to authenticate with Amazon S3. This special signing key is an Access Key/Secret Key pair. Oracle provides the Access Key that is associated with your Console user login. You or your administrator generates the Customer Secret key to pair with the Access Key.

Each user created in the IAM service automatically has the ability to create, update, and delete their own Customer Secret keys in the Console or the API. An administrator does not need to create a policy to give a user those abilities. Administrators (or anyone with permission to the tenancy) also have the ability to manage Customer Secret keys for other users.

Any user of the Amazon S3 Compatibility API with Object Storage needs permission to work with the service. If you're not sure if you have permission, contact your administrator. For information about policies, see How Policies Work. For basic policies that enable use of Object Storage, see Common Policies.

Customer Secret keys do not expire. Each user can have up to two Customer Secret keys at a time. To create keys using the Console, see To create a Customer Secret key.

Working with OAuth 2.0 Client Credentials

Note

OAuth 2.0 Client Credentials are not available in the United Kingdom Government Cloud (OC4).
OAuth 2.0 client credentials are required to interact programmatically with those services that use the OAuth 2.0 authorization protocol. The credentials enable you to obtain a secure token to access those service REST API endpoints. The allowed actions and endpoints granted by the token depend on the scopes (permissions) that you select when you generate the credentials. The services that use the OAuth 2.0 protocol are:
  • Oracle Analytics Cloud
  • Oracle Integration

An OAuth 2.0 access token is valid for 3600 seconds (1 hour).

To create the credentials, you need to know the service resource and scope. Typically, you can select these from a drop-down list. However, if the information is not available in the list, you can manually enter the resource and scope. The scope defines the allowed permissions for the token, so ensure to set the scope at the minimum required access level.

A user can create the credentials for themselves or an Administrator can create the credentials for another user. The lists of available resources and scopes display only those resources and permission levels that the user has been granted access to.

OAuth 2.0 Client Credential Limits

Each user can have up to 10 OAuth 2.0 client credentials. You can increase this limit by Requesting a Service Limit Increase.

Each OAuth 2.0 client credential can have up to 10 scopes.

Obtaining an OAuth 2.0 Access Token

To obtain the token, use your credentials in a request against the OAuth2 token service endpoint as follows:

  1. Create the OAuth 2.0 client credentials. See To create OAuth 2.0 client credentials.

    After you create the OAuth 2.0 client credential note the following information:

    • The generated secret
    • The OCID of the OAuth 2.0 client credential
    • The scope and audience (fully-qualifed scope)
  2. Using the information from the previous step, make a request against the /oauth2/token endpoint to obtain a token as follows:
    curl -k -X POST -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" --user '<Oauth 2.0 client credential OCID>:<credential secret>'  https://auth.<oci_region>.oraclecloud.com/oauth2/token -d 'grant_type=client_credentials&scope=<audience>-<scope>'

Where:

  • <Oauth 2.0 client credential OCID>:<credential secret> is the OCID of the OAuth 2.0 client credential that you created joined by a colon (:) with the generated secret for the credential. Note that this secret is only displayed at the time you generate it and it must be copied immediately. You can retrieve the OCID from the details of the credential at any time.
  • https://auth.<oci_region>.oraclecloud.com/oauth2/token is the Oracle Cloud Infrastructure OAuth 2.0 authorization endpoint where <OCI_region> is a region your tenancy is subscribed to. For example, us-ashburn-1.
  • <scope>-<audience> is the fully-qualifed scope, that is, the scope and audience joined by a hyphen (-). The scope and audience are available from the details page of the credential.

Example request:

curl -k -X POST -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" --user 'ocid1.credential.region1..aaaaaaexamplestringaapgpedxq:{SAMplESeCreta5y'  https://auth.us-ashburn-1.oraclecloud.com/oauth2/token -d 'grant_type=client_credentials&scope=https://2aexampley3uytc.analytics.ocp.oraclecloud.com-urn:opc:resource:consumer::all'

The response will include the token. Example response:

{
"access_token" : "eyJraWQiOiJhcDVfwqKdi...8lTILrzc4cof2A",
"token_type" : "Bearer",
"expires_in" : "3600"
}

The token string is truncated in the example response. Copy the entire access_token string (within the quotation marks) as shown in your response.

Using the OAuth 2.0 Token in a Request

After you obtain an OAuth 2.0 access token, you provide the token in a bearer token header of the REST API request.

For example:

curl -i -X GET -H "Authorization: Bearer <token-string>" "https://<audience>/<rest-endpoint-path>"

What to Do When the Token Expires

The token expires after 3600 seconds (1 hour). When the token expires, request a new token following the instructions in Obtaining an OAuth 2.0 Access Token.

Adding Scopes

You can add scopes to an existing OAuth 2.0 client credential to add access to more services with the same credential. After you add scopes, you do not need to regenerate the secret.

To request a token for multiple scopes, You can include additional scopes in a token request by appending

&scope=<scope>-<<audience>

to the final argument of the request and specifying the scope and audience for the scope you want to add.

Working with SMTP Credentials

Simple Mail Transfer Protocol (SMTP) credentials are needed in order to send email through the Email Delivery service. Each user is limited to a maximum of two SMTP credentials. If more than two are required, they must be generated on other existing users or additional users must be created.

Note

You cannot change your SMTP username or password to a string of your own choice. The credentials are always Oracle-generated strings.

Each user created in the IAM service automatically has the ability to create and delete their own SMTP credentials in the Console or the API. An administrator does not need to create a policy to give a user those abilities. Administrators (or anyone with permission to the tenancy) also have the ability to manage SMTP credentials for other users.

Tip

Although each user can create and delete their own credentials, it is a security best practice to create a new user and generate SMTP credentials on this user rather than generating SMTP credentials on your Console user that already has permissions assigned to it.

SMTP credentials do not expire. Each user can have up to two credentials at a time. To get SMTP credentials in the Console, see To generate SMTP credentials.

For information about using the Email Delivery service, see Overview of the Email Delivery Service.

Working with IAM Database User Names and Passwords

Easier to use

Database end users can easily use IAM database passwords because they can continue to use a well-known authentication method to access the database. You can access database passwords that you manage through your OCI profile after you successfully authenticate to OCI.

Before users can access or manage their database password, IAM administrators can create an extra layer of protection by enforcing multifactor authentication using Managing Multifactor Authentication. For example, this can be a FIDO authenticator, or by pushing notifications through authenticator applications.

IAM Database Password Security

Using IAM database usernames and IAM database passwords to access databases improves security because they allow IAM administrators to centrally manage users and user access to database passwords within IAM instead of locally in each database. When a user leaves an organization, their IAM account is suspended and therefore, their access to all databases are automatically suspended. This method removes the possibility of unauthorized accounts being left on database servers after a user has left. For more information, see IAM Database Passwords. See the Oracle Security Guide, Chapter 7 for information about how IAM users authenticate and authorize to OCI databases.

IAM Database User Names

If your OCI IAM database username is longer than 128 bytes, you must set a different database username and a database password that is less than 128 bytes. IAM enforces the uniqueness of database usernames within a tenancy. The database user name is not case-sensitive and has the same allowable characters as an IAM user name (ASCII letters, numerals, hyphens, periods, underscores, +, and @)). This is more restrictive than local database usernames, which are governed by the character set of the database. See Database Object Names and Qualifiers for more information.

To create, change, and delete IAM database user names, see Working with IAM Database User Names.

Alternate IAM Database User Names

You can create an alternate IAM database user name that contains only letters and numbers, does not include special characters, and can be shorter than regular IAM database user names.

You can create an alternate IAM database user name:

  • If your user name is too long or hard to type
  • To make logging in easier with a user name that does not include special characters

IAM Database Password Specifications

The IAM database password complexity uses almost the same rules supported in IAM for Console passwords (no double quotes ["] in IAM passwords). For details, see Creating an IAM database password.

Failed Login Lockouts

For information about failed logins, see IAM Database Password Lockouts.

Password Rollovers

Applications have a password in a wallet or other secure mechanism and in the database. When changing a database password, you also need to change the password in the application wallet. You normally do this during application downtime. However, having a second password allows you to change passwords without application downtime. Since both passwords are usable, the application admin can swap passwords in the application wallet files at their convenience, and can remove the old password from IAM later. This is independent of the database gradual password rollover status in the database. The database still reflects open status, that is, not open and in rollover.

Using the Console

Using the API

For information about using the API and signing requests, see REST API documentation and Security Credentials. For information about SDKs, see SDKs and the CLI.

Use this API operation to manage Console passwords and access:

  • CreateOrResetUIPassword: This generates a new one-time Console password for the user. The next time the user signs in to the Console, they'll be prompted to change the password.
  • UpdateUserState: Unblocks a user who has tried to sign in 10 times in a row unsuccessfully.

Use these API operations to manage API signing keys:

Use these API operations to manage auth tokens:

Use these API operations to manage Customer Secret keys:

Use these API operations to manage OAuth 2.0 client credentials:

Use these API operations to manage SMTP credentials: