OAuth 2.0 Quick Links


This IBM Identity Demo includes an OAuth 2.0 Service Provider, a resource protected using OAuth, and three different OAuth demonstration clients.

To test the OAuth capability using the most common type of flow (authorization code), follow these steps:

  • Create some attributes for your account (as the resource owner) using the Manage your attribute information page. Create values for attributes called email and phone. These will be returned as data in the protected resource.
  • Register a new OAuth client at the Manage OAuth Client Registrations page. Be sure to register the client using the "Configure For Demo Client" helper button to populate the Redirect URI for use with our test client. Record your Client Id and Client Secret for later use.
  • Visit the Authorization Code Demonstration Client and use your Client Id and Client Secret to run the flow.

If you are familiar with OAuth and are looking to use your own OAuth client with this demonstration server, here are the key configuration items for the server that you need to know about:

Authorization Endpoint

Redirect to this endpoint to initiate an OAuth 2.0 flow. Your redirect should also include the client_id, response_type (code or token), redirect_uri and scope parameters, for example:

https://tfim01.demos.ibm.com/FIM/sps/oauth20sp/oauth20/authorize?client_id=key&response_type=code&scope=phone email&redirect_uri=https://myhost.com/myclient

Token Endpoint

This endpoint is used by your OAuth 2.0 client to exchange authorization grants for tokens. It supports the code, token, refresh_token, and client_credentials grant types. Note that Tivoli Federated Identity Manager also supports the password grant type however that is not available in this demonstration environment. Authentication of a client at the token endpoint is only supported by passing the client_id and client_secret parameters in the post body. The endpoint does not support basic authentication.

Protected Resource

This URL is protected by OAuth (requires presentation of an access token) and returns a JSON string containing profile attributes of the resource owner granting authorization. There is one exception to this, and that is when using the client_credentials flow the attributes will be returned from the profile of the user who registered that OAuth client as the client identity itself does not have a user profile.

The JSON string returned for the protected resource will always contain two single-valued server-generated attributes (username and timestamp), and may contain other (multi-valued) attributes as a JSON array of strings as determined by the scope requested by the client and authorized by the resource owner. Extra scope attributes will only be included if the resource owner grants access, and a value exists for that attribute in the resource owners profile. To add/delete/manage your attributes as a resource owner, visit the Manage your attribute information page.

An example of the protected resource format is shown here:


Client Registration


This page allows you to interactively self-register your OAuth 2.0 client.

Note that you will not be able to easily use the implicit grant flow with any client other than the demonstration client included on this site. The reason for this relates to the same-origin policy for AJAX. The browser by default can only make AJAX requests to the same host as the source of the page containing the AJAX code. As our protected resource is located on the tfim01.demos.ibm.com server, you require the page containing the AJAX javascript to be loaded from the same host. There are some workarounds for this available and the most straight forward if you really want to test the implicit grant flow is to write your own proxy resource which uses the access token at the server side to access our protected resource directly.