Token-Based Security, OAuth, OIDC and IdentityServer4 – Part 3
In this post we'll configure IdentityServer with test users and simple clients. We'll also see simple implementations of different OAuth flows.
Join the DZone community and get the full member experience.Join For Free
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.
Setting up Test Users
Let’s set up a couple of test users in IdentityServer for our testing purposes:
These are temporary users to help us debug/test the identity server.
Setting up Test Clients
We talked about different types of client applications in previous posts. We also talked about the OAuth2.1 recommended flows.
In the config.cs file, I created the following client:
Update ASP .NET Core Middleware with Test Users and Client
Then, we can use these in the identity-server middleware in a startup.cs file:
We are still using InMemory persistence for various configurations, which is OK for these demos and once we are done with our testing, we will replace these with database persistence.
Client Credentials Flow
As we’ve previously learned that this flow is useful for server-to-server communication (or a machine-to-machine). With the configurations in place, let's test if we can get the token from IDP. Start the application and for the client app, we can use postman for now:
As you can see the post request was successful and we get an access token from IDP as expected.
If are curious to know that see what’s inside this access token, We can decode this token using the jwti.io website:
Now, for testing purposes, if I use the wrong information for the post request, the following results will show up:
This is the basics of client credentials flow. We will see more real-world examples later in the series.
Let’s try a slightly different flow next:
Resource Owner Password and Client Credentials
I created a client with the following configurations:
and here is how the postman request is setup:
As you can see, we are using
/connect/token endpoint to retrieve the token from the server. For parameters, we provide client_id, client_secret, password as a grant_type because we want to exchange user credentials for the token, and username and password.
In this post, we configured IdentityServer with some test users and simple clients and then used Postman for demo purposes. The journey is not yet over and will resume our learning in the next post. Let me know if you have any comments or questions. You can get the demo code for this in the GitHub repository. Till next time, Happy Coding.
Published at DZone with permission of Jawad Hasan Shani. See the original article here.
Opinions expressed by DZone contributors are their own.