A short introduction to Authentication in Web Apps / Single Page Applications with cidaas (OIDC/OAuth2)
This story focuses on the user authentication in Web Apps / Single Page Applications using the OpenID Connect and OAuth2 Standards as well as the Cloud Identity & Access Management cidaas.
cidaas (https://www.cidaas.com) is a modern Cloud Identity & Access Management solution developed by Widas ID located in Germany. The cidaas feature set includes:
- Single Sign On (SSO) based on OAuth2, OpenID Connect, SAML 2.0
- Multi-Factor-Authentication with more than 14 authentication methods, including TOTP and FIDO2
- Passwordless Authentication
- Social Login (e.g. Facebook, Google, LinkedIn, and more) as well as Enterprise Identity Provider (e.g. SAML or AD)
- Security in Machine-to-Machine (M2M) and IoT
A short introduction on OAuth2 and OpenID Connect
OAuth2 is the industry-standard protocol for authorization, and it provides different authorization flows depending on the application or client type, be it for example web or mobile applications. If you want to learn more about OAuth2 have a look at the official website at https://oauth.net/2/.
OpenID Connect (OIDC) is a standard authentication protocol that adds an identification layer to the previous OAuth 2.0 standard. OIDC provides information to the end user in the form of an id token, through which the identity is verified. The standard is controlled by the OpenID Foundation (https://openid.net).
The cidaas JavaScript SDK
Let’s get started by integrating the cidaas JavaScript SDK in a simple HTML page. The cidaas JavaScript SDK is publicly available on the cidaas github repository — https://github.com/Cidaas/cidaas-javascript-sdk
The integration of the cidaas SDK is quite simple — it can be imported as script via the CDN of cidaas, as shown below:
<script src=”http://cdn.cidaas.de/javascript/oidc/1.2.0/cidaas-javascript-sdk.min.js"></script>
What’s next? — The initialization of the SDK:
While initializing the cidaas SDK we pass an options variable that contains a set of parameters required for the OpenID Connect and OAuth2 flows. First, we pass the authority which is basically the base URL of the cidaas tenant you are using — if you do not have a cidaas instance, you can sign up for a free cidaas Plan online (cidaas Free Plan). Next we are passing the client_id and redirect_uri of our App in the cidaas tenant. If you need some information how to create an App (OAuth2 / OpenID Connect Client) in cidaas please refer to: docs.cidaas.com
Additionally, we have to pass some parameters required for the actual flows, this is especially the response_type. The Response Type parameter manages if we want to get back the authorization of a user directly as a token, e.g. as a parameter in the url, or if we want to get back a code which we exchange to a token. We recommend to use the Code Flow which prevents sharing the token publicly in the url. Moreover, it is best to use the PKCE flow to exchange the code to a token, instead of using a global Client Secret. But no worries on this, the cidaas SDK handles all that for you, so we just have to give code as parameter in the response_type and the SDK will do the trick. Next, we have to give the scopes we want to request — if you want to learn more about what scopes exactly are and how you can utilize them in cidaas, have a look at: docs.cidaas.com.
Last, we need to give the mode, this parameter defines the mechanism how the login page will be called, in our example we use redirect. To get an idea what mode means:
- redirect — You will be redirected to the login page
- window — The login page will be opened in a new window
- silent — Will initiate a silent login
What’s left to do is to use the cidaas SDK to perform an authorization/authentication. The easiest way is to call the cidaas.loginWithBrowser(); method, the SDK will then redirect to the login page on which the user can authenticate and will return after a successful authentication or a cancel event back to the redirect url configured in the options.
After we started the authentication/authorization process we now need to handle the callback to our application. As described above we either have a successful authentication or a cancel event. The cidaas SDK also provides the required functions for doing this.
On the page we redirect to, in our case …, we need the call the loginCallback method and in this, handle the successful and failed case. In the successful case, we get back the token, even so we used the code response_type, since cidaas has already exchanged the code to a token in the background. We now can use the token to get the user data or authorize against other apis. In the failure case we can just log the exception or present the user with a helpful message.
That’s it we made it! We now can easily integrate the cidaas JavaScript SDK into any JavaScript application.
Hint: If you want to have a look what is in the token we get back in the callback method, you can decode your Access Token easily with the https://authkit.io/ online jwt decoder.
Securing your Web Apps and Single Page Applications and managing users is important and with the OAuth2 and OpenID Connect Standards it becomes easy for consumers and developers to achieve it. This example based on the cidaas — Cloud Identity & Access Management & cidaas-javascript-sdk — shows how easy it can be integrated into any JavaScript application.
If you have any questions or suggestions, please leave a comment.
