0
votes

I've got 2 different .NET Core 2.2 MVC projects. I'm using IdentityServer4 for the token server, Azure B2C for the identity store.

The 1st MVC app is a normal MVC application, and I've got it working perfectly with the OIDC Hybrid flow.

The 2nd MVC app is an Angular 7 cli app, which serves up the index.html and houses the API that the app will be calling. The angular app will not call any other APIs directly (gateway pattern).

My questions are about the 2nd app - I'm trying to figure out the best way to set up the Angular app for security.

My understanding is: OIDC Implicit flow exposes exposes the access token on the browser. OIDC Hybrid flow does not expose the access token (at least when hitting the same web server - no CORS), because the web server (client) uses the back channel to obtain the access token, via the authorization code, and its never exposed to the browser.

QUESTION #1: Is my understanding of Implicit vs. Hybrid correct?

If my understanding is correct, I'd think the best way to go would be Hybrid flow even for the Angular app, but most samples I've seen for using OIDC with Angular involve the Implicit flow, and don't take advantage of the authorization code / backchannel. Avoiding having an access token on the browser seems like a big deal, like a worthy goal, but wondering why it doesn't seem to be done?

QUESTION #2: I'm serving up my Angular index.html from my MVC server - why can't I just use Hybrid flow to protect the index.html page, and keep the token on the backchannel?

Something tells me my understanding of all this isn't quite complete...

1
In browser scenarios you'd typically use implicit, otherwise you'd need to expose the client secret to the web application, which you certainly shouldn't. Typically, access tokens should be valid for a short period of time, thus limiting the damage a stolen token could do. - Knelis

1 Answers

0
votes

Your understanding is correct. You can protect your index.html. The only problem you will face that way is that it's not the default configuration for today. With your requirements, most likely you don't need any of oidc client libs at all, you can protect your (only) API with a (same-site, http-only) cookie (not a bearer token) and in your Angular guards just ensure that you are still logged in to your back (if not, redirect through a local MVC resource to involve server-side code into login procedure).

See this question, especially the comments and link below for further reference.