Asp.Net Core API OpenId-Connect authentication with JWT token using IdentityModel

Question

I have an ASP.NET Core API as back-end for an Angular SPA front-end. I am using Cognito as an Identity provider and want to create an OpenId-Connect authentication using authorization code flow which would mean that all the secret credentials will be stored in back-end.

The authorization flow should be like this (standard OpenID Connect flow):

1. FE application calls /authorize endpoint and is redirected to Cognito hosted UI.
2. After entering credentials FE receives an authorization code.
3. FE calls BE with authorization code.
4. BE calls /token endpoint and receives accessToken and refreshToken.
5. BE Returns accessToken to FE and sets refreshToken as httpOnly cookie(for this not sure, I may store it in Redis cache).

Then, FE with each request will add Bearer AccessToken to authenticate. When AccessToken is close to expiration, it will be updated using refreshToken.

I was experimenting with this example but here application used an Asp.Net Core cookie for authentication and ignored accessToken and refreshToken. I was authenticated even after accessToken was expired. Also, there's not much documentation on how ASP.NET cookie works.

So, now I am thinking about having my custom BE endpoints and use IdentityModel helper methods but not sure if it is a good practice to handle authentication like this.

• /Login - gets AccessToken and RefreshToken
• /Refresh - updates AccessToken using RefreshToken. FE will call it manually when accessToken will be close to expiration.

So, is there a "recommended" way to handle this scenario nicely with IdentityModel without writing custom implementation?

Also, as far as I know, it is quite common to store refreshToken in httpOnly cookie which will be added to each request sent to BE but then I don't see the point of having an accessToken when I already have refreshToken added with each request.

Isn't it better to store refreshToken inside BE for performance and security reasons?

Authentication is a part of every application so I believe there should be some in-built framework functionality for authorization code flow as well.

Answer 1

You are describing a Backend for Frontend approach, which is a good architecture. Make sure you separate the specialist API that deals with OAuth from general business APIs.

RECOMMENDED WAY

Curity have an approach that provides state-of-the-art security for SPAs, here are some links:

• Token Handler Blog Post
• Code Example
• Code Example Doc

We may add a .Net token handler at some point, but it should not matter what tech is used, since the idea is for the specialist API to be something you plug in rather than code.

STORING REFRESH TOKENS

My personal preference for SPAs is to use AES256 encrypted HTTP only cookies. This fits nicely with goals of avoiding OAuth plumbing in applications and enables the token handler to be stateless and easier to deploy + manage.