There are several ways to test an OAuth flow and different tools that can be used in the process. In this article we will take a look at how to use cURL and a browser to run through the Code Flow.
Start in the browser, the following example URL will result in the Authenticator configured for the
www client to be triggered. The
response_type indicates that we want a code and we have to provide a
redirect_uri that matches what has been configured in the client in Curity.
localhost:8443 to match the hostname and port of your installation of the Curity Identity Server. This should match the configured
Base URL in System -> General in the Curity admin UI.
The username-password authenticator created previously is configured to be used with the client we created. If an account is available, use it to log in. If this is the first time running though this test chances are that no account exists.
The username/password authenticator can handle registration.
Create Account, on the next screen, fill out the information for the new account. Username, email and password are mandatory fields. Click the
Create account button.
When the account creation is complete there is an option to
Return to login.
After a successful authentication the browser redirects to a URL that looks like this:
The part we need for the next step is the code
Note here that we got redirected to the
redirect_uri that we passed in our original request to the server.
The next step in the code flow is a
POST to the token endpoint of the Curity Identity Server. Here we need to also authenticate the client. The client we use is configured to use
secret as the authentication mechanism, so we can simply add
-u www:Password1 to our request.
We also send the grant_type, redirect_uri, code and as url encoded parameters.
curl -Ssk \ https://localhost:8443/oauth/v2/oauth-token \ -u www:Password1 \ -d grant_type=authorization_code \ -d redirect_uri=https%3A%2F%2Flocalhost%2Fcallback \ -d code=k6sdxUQjtZiaDjAJsH2bDWBwknZ6XXjb
-k flag of
curl is there because the default certificate generated by install is self signed and not trusted by
curl. If the default certificate is replaced by a trusted one, the
-k is no longer needed.
The response looks something like this:
We have now received an Access Token, a Refresh Token and an ID Token. The ID token is issued thanks to the fact that we requested the
This concludes the basic “Getting started” track. Head over to the summary article that also covers further suggested reading on additional advanced configuration and integration options.
Let’s Stay in Touch!
Get the latest on identity management, API Security and authentication straight to your inbox.