In previous post of this series, we configured our Angular application as a client of IdnentityServer and completed the login/logout process.
However even though user was logged-in, the REST API calls were still not authorized:
In previous post, on the topic of Token Based Security, we created an API endpoint and protect it (using Authorize attribute) with IdentityServer. Then we setup a simple Angular application with an AuthService to use oidc-client library. We also created few angular components and at the end of previous post, we created two buttons for login/logout purposes in appComponent and then wired the following method with click events:
I have written few posts on token based security, its importance, OAUTH, OIDC and IdentityServer. You can check previous post if you are new to these topics.
Today, I will write about how to secure angular application with these technologies. We will see how to wire Angular application with IdentityServer.
Angular application is a public client type of application, these applications are not capable of keeping a secret like server-side client applications e.g. ASP .NET MVC, Nodejs etc.
In the past Implicit flow was used for angular but its no longer recommended. …
We have been discussing different parts of various Authentication and or Authorization requirement scenarios. We also covered some theory and saw some demo code regarding OAUTH, OIDC, Identity Server, etc.
In the previous post, we learned how to configure IdentityServer, AllowedScope of a client application, and how to make a PasswordTokenRequest for the scopes to UserInfo Endpoint.
Currently, our IDP is running as a web application without a User Interface.
Typically an IDP will be needing some UI for different Authentication and or Authorization purposes e.g. Login, Logout, Change Password, Consent Screens, etc.
Fortunately, the IdentityServer team put together a…
In previous post of this series, we saw different flows to get the token from IdentityServer and then pass those token as Authorization Headers in our HTTP Calls and client application was able to get the data as expected.
Today, we will continue our journey and learn more about users and claims. So, if you are new to IdentityServer, I will suggest to read the previous posts in this series for some background information.
Earlier, we had setup couple of Test users in IdentityServer (Config.cs file). Here is the part about that setup for one of the user:
In the previous post of this series, we set up IdentityServer with some test users and client configurations. We then used the postman tool to get the access token with a couple of different flows.
In this post, we will move forward and add a resource API to our solution. This will be a simple .NET Core WebAPI application. This API will contain endpoints that different client applications will call. We will protect this API using IdentityServer.
We will then access this API from client applications. We will keep using the Postman tool and also add a .NET Core WebApi…
In the previous post in this series, we discussed token-based security, OAuth, and OIDC. We also configured IdentityServer4 with some configurations.
In this post, we will continue configuring IdentityServer4 and will also learn some of the client/server communication following OIDC flows.
If you are new to OAuth, IdentityServer, or Token-based security in general, then I will suggest reading the earlier posts in this series and then it will be easier to follow the concepts we will discuss today.
Let’s setup a couple of test users in IdentityServer for our testing purposes:
In my previous post, we learned that OAuth is an authorization framework specially built for HTTP APIs. It allows a user to securely delegate scoped API Access to an application.
By scoped access means, that users define exactly what parts of an API, they want the application to be allowed to use. This application can then talk to API freely on the user's behalf. In simple words, OAuth is a delegation protocol.
We also learned that OpenID Connect is a standard adding authentication (verifying the user’s identity) on top of OAuth2, which is only for authorization (access control). …
Mostly, We all know the username/password mechanism of login to a web application. We also might have heard, used or implemented authentication/authorization systems, with or without frameworks.
In this context, Token-based security is one of the common mechanisms to secure backend APIs.
A typical common architecture for web applications consist of a web-client app (e.g. an Angular or React frontend), a backend API (written in .NET Core, Java or NodeJS) and database for persistent.
In token based security, generally a web-client send token, representing consent, to an API. So, Instead of sending over Username, Password on each call to the…
In the previous few posts in this series, we deployed and ran a couple of applications on our EC2 based infrastructure. Here is how our architecture currently looks like from the previous post:
Our applications are running in a private subnet and NGNIX working as a reverse proxy is allowing access over the internet.
Today, we will just run yet another .NET core application on a same private EC2 instance. Just like in the previous post, we will serve this application using NGNIX. However, this time application will be running as a docker container.
Docker is a great tool to…
Hi there! I’m Jawad and I’m a software Solutions Team Lead. I live in Dusseldorf, Germany, have a great interest in books and movies, and Astrophysics as well.