Identity as a Service (IDaaS) — Okta & ASP Net Core
In the previous article, we discussed identity as service providers — Identity-as-a-Service — AWS Cognito and Okta. Now let’s see how we can use one of them, Okta with an ASP Net Core web application.
For this example, we only need an email account and Visual Studio. The Community version is more than enough.
All code for this example is available on GitHub.
Web App
First, we create a Web Application in ASP Net Core in Visual Studio 2017. In this case, the app that creates by default is enough. Configuring Authentication in ASP Net Core 2.0 is very simple, most of the changes in startup.cs. But before we start setting up the app, we have to have our Identity service as a Service. Let’s start with the configuration in Okta.
Okta — New Account
In the Okta Developer site, you can create a new account. After completing the form, it shows us the welcome message. We also received an email from Okta to confirm our account and the temporary password to access our new account.
After confirming, changing the password and other security questions, we have access to the console, which includes the links to Okta’s quick start guides for different front-end and back-end technologies.
The first thing we have to do next is to create the entry of our app, to allow it to contact Okta to identify the users. This is achieved from the Applications menu, then on that page, by pressing the Add Application button. The selection of the application type directly impacts flow the OAuth flows that will be used in the app. For example, SPA — Single Page App — only allows implicit since the JavaScript is vulnerable to other types. For this example, we are going to choose the Web type and use the Authorization Code flow, which is the default option.
The form to create the app has two values to configure: Base URIs and Login redirect URIs. Although the guide mentions another value, Logout redirect URI, we can not modify it until later when the app has been created. These three values depend on the configuration of our web app, mainly the port where it will run on localhost.
Something that in the past needed to be done and that Okta now does automatically at the time of creation is to assign the domain to the Trusted Origins list. But if for some reason we have to change the domains of our app, we must make the change manually not only in the app in Okta but also in the menu option API> Trusted Origins.
The complete article is available in DZone Security
Artículo en español
Todas las opiniones expresadas son mías y no representan opiniones de ninguna entidad con la que he estado, estoy o estaré afiliado.
All views expressed are my own and do not represent opinions of any entity whatsoever with which I have been, am now, or will be affiliated.
