A quick-start guide for connecting a stand-alone, in-browser AngularJS-based web application to the 10Duke Identity Provider, with Implicit Grant Flow


The 10Duke Identity Provider (IdP) API offers a quick and simple means of providing users access to cloud and corporate applications using a single identity. You can connect any application to the 10Duke IdP and each time a user tries to login, the 10Duke IdP will authenticate the user for your application.


This tutorial covers implementing authentication in your stand-alone, in browser AngularJS-based web application with the 10Duke Identity Provider by using the OAuth 2.0 with OpenID Connect. Once you have connected your first client application to the IdP, you can then connect further applications in order to create a Single Sign-On system between all connected client applications.

Entities in the solution

For this tutorial you will need:

  • A deployment of the 10Duke Identity Provider. Please contact us to get this deployed for you.
  • Your test environment for your AngularJS application

Solution entities Diagram 1: Solution entities

API / Service endpoints

You will be calling the following endpoints in this tutorial:

Item URL ​(relative,​ ​prepend​ ​environment​ ​base​ ​URL)
Authorization code /oauth2/authz
Access token /oauth2/access
User info /userinfo

Step 1. Create a profile in the IdP

As a first step, please register yourself as a test user and create an account in the Identity Provider.

Step 2. Register your application with the 10Duke IdP

Next, we will need to collect some basic information about your application to configure a new client and issue the client_id.

Please send the below details to support@10Duke.com and we will respond by email:

  1. Your app name e.g. myapp

  2. The Login callback URL (redirect_uri > this is the url used to redirect the user agent after a successful authentication). This normally looks like https://myapp.companyname.com/login/callback

  3. (Optional) Logout callback URL (this is the url used to redirect the user agent after a successful logout)

Note: local deployments are fine as well, e.g. a dev deploy URL in form http://localhost:8084/ with login callback at e.g. http://localhost:8084/login/callback

Step 3. Get your application keys

Once you have provided us with your app name and login callback url, we will provide you with the client ID and client secret. Your application will need this information about the client to communicate with the IdP.

Client_id = YOUR_CLIENT_ID

10Duke IdP deployment: https://test-idp.10duke.com/your_app

Step 4. Choose your OAuth 2.0 SSO Variant

When implementing SSO generally, there are several approaches you can take. These variants depend on the types of application you are connecting to the SSO system (mobile, web, or desktop) and if you’re working with OAuth 2 or SAML 2. To learn more, please see the IdP Developer Guide and the “Single Sign-On Variants” section of it.

For this tutorial, we’ll use Implicit Flow. This example applies in the case of a browser / desktop application interacts with the user and IdP directly without its own server side involved at all.

  1. First the browser is directed to the Idp (authorization server) . “Sends” here can be done using JavaScript code or predefining a link / button that contains the URL to navigate to. The call below shows what pressing a link in the web page looks like:

    GET /oauth2/authz/?response_type=token+id_token&scope=profile+email&client_id=todo_api_key&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&state=xyz&nonce=todo_nonce HTTP/1.1
    Host: {IDP_HOST}
  2. Next, once the user was successfully authenticated, the IdP (authorization server) redirects the browser back to the client (client web application)

    HTTP/1.1 302 Found
    Location: https://client.example.com/cb#access_token=bNXrLNRSR-hWHRa109MUcYagUGM&token_type=Bearer&expires_in=31536000&state=xyz&id_token=e2F0X2hhc2g6IHlLTE1IRlhrNEo3TzBpMS1WejM1Wnc9PSxzdWI6IGRhMjFhOWZiLTU5NmItNGI3MS1hODZmLWM0Y2YyN2RlN2ZlZSxhdWQ6IHRvZG9fYXBpX2tleSxpc3M6IGh0dHBzOi8ve0lEUF9IT1NUfTo0NDMsZXhwOiAxNTE1ODQ4MTcwLGdpdmVuX25hbWU6IFRlc3QsaWF0OiAxNTE1NzYxNzcwLG5vbmNlOiBhZGQxMmQxYy1jNzZiLTQwYzYtODhlZS1iYzQwMDNkNTQ1NGYsZmFtaWx5X25hbWU6IFVzZXJ9
  3. The client will next parse the request URL and extract the access token. The login callback information is contained in URL parameter format in the URL fragment (after the # character in the URL)

  4. Next the client may use IdP API endpoints, including the /users endpoint to fetch more information about the logged in user. Any subsequent call should include the OAuth 2.0 Access Token in the Authorization header. For more information see the the 10Duke REST API

  5. Please see https://github.com/10Duke/ng-client-idp for a practical NG client application example.

Step 5. Confirming delegation of authentication to the 10Duke IdP

Congratulations! If you have integrated your test application to the IdP correctly you should now be able to sign-in to your test application and see it delegate authentication to the IdP (watch your browser urls change as it does this) and then return you, as a logged-in user, back to your test application.

If you run into any issues, please raise them on StackOverflow, tag them “10Duke”, and we’ll respond asap.