I'm implementing a RESTful web service using ASP.Net Web Api and Backbone.js at client side. What will the best way to authenticate user?
You are building SPA then it is recommend to use Token Based Authentication not Cookies, once you obtain the access token from the Auth server (Web API) you need to store it in html5 local storage then with each subsequent request to a protected resource you need to send this access token in the "Authorization" header using bearer scheme.
I've compiled detailed post about this but it uses Angular, so it will be very close to backbone.js
Related
Vue front-end for SPA and asp.net core 3.1 as backend for API
Using Microsoft.AspNetCore.SpaServices.Extensions nuget package so, among others, SPA files will be served from a folder (wwwroot/dist) when users access .net core
Back end API controller is decorated with [Authorize] attribute
SPA router has authguards so protected routes are only available to authenticated users
SPA will use Axios and pass a bearer token to the back end API
I want to implement OAuth2/Oidc authorization code with pkce using the identityserver4 hosted on another system.
A request for the landing page should forward the user to identityserver4 for the login/password prompt and redirect back after completing all the steps with a token.
Ideally I want the .net core handle all the oauth/oidc steps and don't want to deal with it using oidc-client javascript client in SPA. Any suggestion on how I can accomplish this? Thanks
Well there are two standard models here and you need to choose one of them, depending on factors you care most about:
OPTION 1: SPA SCENARIO
The SPA is the OAuth client and authenticates via Javascript tech
The API is the OAuth resource server
It is not standard for a resource server to handle the authentication flow for a client - instead a client should authenticate, then call the resource server.
OPTION 2: WEB BACK END SCENARIO
People most commonly choose this option when they want to keep tokens out of the browser's Javascript code:
A Web Back End in C# is the OAuth client
The Web Back End needs to securely communicate with the browser and has to use an auth cookie for this
To call an API the browser needs to either send the cookie to the web back end to get a token, or double hop all API calls via the web back end
ABOUT OIDC CLIENT
Personally I prefer option 1, which I think is closer to overall SPA Goals, such as cross domain hosting and use of content delivery networks. OIDC Client can actually lead to a fairly simple SPA security implementation, as in this
Client Side Implementation of mine.
I am developing web Application in .Net Core 3. I need to manage authentication and authorization in web app based on the JWT token received from other rest API application. Is it possible to manage role based based page and navigation between them without using/creating the database for web app? How to manage token expiration for web application if we are able to manage that?
You can add same token validation parameters as you have in your other rest API app with same IssuerSigningKey, and use tokens with your main app as well
I am creating a new .Net Core Web API that is consumed by a new React client-side app. Both the client-side app and the Web API are on different hosts and protected by Auth0. I set up both the client-side app and the Web API in Auth0, and then I created a machine-to-machine app in Auth0 to be able to communicate with the Web API silently (without a user interface). The security flow works like this:
User tries to access client-side app.
User is re-directed to Auth0 to provide credentials.
Auth0 authenticates the credentials and returns user info (including user ID + access token) to client-side app.
Client-side app stores user info in local storage for future use until it expires.
Any calls to 3rd party APIs are routed through my own Web API, so 3rd party API keys are sitting in a safe place on the server, not on the client-side.
User accesses a page that requires a call to my Web API but we don't have an access token for my Web API yet.
Client-side app reads the ClientId & ClientSecret (hard-coded values) from .env file and makes a POST request to Auth0 to fetch an access token for my Web API (this is Auth0's recommended way of getting the access token for the Web API silently except they don't specify where the ClientId & ClientSecret would be stored).
Auth0 returns an access token for my Web API.
Client-side app stores the Web API access token in local storage for future use until it expires.
Client-side app invokes my Web API with newly acquired access token as the bearer token in the header.
Web API receives the access token, authenticates with Auth0 and fulfills the request.
All of the above is working for me but I am concerned about storing the Auth0 ClientSecret of my Web API in the client-side app. Although it is not visible on the screen or in a cookie anywhere, any capable user would be able to get at it by inspecting the network traffic.
Many people on the Internet seem to be fine with storing 3rd party API keys in .env files while others advise routing 3rd party API access through your own Web API ... and I am doing the latter. But I still need the Auth0 ClientSecret to get to my own Web API and I cannot figure out a better place way to get to it without storing them somewhere on the client-side.
One last-ditch solution I can think of is to not protect my Web API through Auth0 and instead every call from the client-side app to my Web API should include something unique (like the user ID from Auth0) that can be validated by the Web API. Thankfully, the user ID from Auth0 will be stored in our database when the user is set up initially, so this is actually possible.
Does Auth0 have any other way for me to get the Web API access token without providing the ClientSecret given that I already have the client-side app's access token? I am curious to know how others have secured both their client-side app and their Web API through Auth0.
You are correct, you should not include the client secret in your client-side app. Do not use a client credentials flow, instead use a auth code + PKCE or implicit flow.
With that being said, Auth0 should handle most of that if you are using a library or SDK.
You have two options for getting the token:
When requesting the initial access token and ID token add the Web API as an audience and request the related scopes.
Make a silent request using the checkSession function for Auth0.js or getTokenSilently for auth0-spa-js
Take a look at this:
https://auth0.com/docs/architecture-scenarios/spa-api/part-3
I have a Web API written using asp.net core. This API will be used to communicate with several other services registered in AAD, which all could be made using different technologies like an MVC application written in asp.net core or a single page application written in Vue.JS. The latter is causing me issues as the SPA won't be run by an application web server and rather something like nginx or apache and therefor won't be able to use a client secret.
I have added API permissions for my API to my apps.
How would I achieve this? I'm currently sending an access token using the Authorization: Bearer access_token header from the client app to the API, but since the client app and the API aren't the same app in the AAD, it's causing issues.
Here's the flow I'm trying to achieve:
All of the requested apps require you to login to the AAD and when requesting data from the API, they'll send the JWT token, which then should validate the token before returning the requested resource back to the client application.
It seems you misunderstand something . You can register your each client as independent application in Azure AD , and assign access permission for your web api .
The latter is causing me issues as the SPA won't be run by an application web server and rather something like nginx or apache and therefor won't be able to use a client secret.
SPA application use Implicit grant flow , so that it doesn't need the client secret when acquiring token .SPA could be independent app , you should provide client id when making authentication with AAD. After getting access token , you could create http request with Authorization: Bearer access_tokenheader for accessing your web api .
Each client(web/spa/native) will acquire access token for accessing web api . On web api side , you just need to validate the token .Validate the claims(issuer,audience) and signature .
We are current building a collection of back-end ASP.NET Core microservices. These services will not be accessed directly from the front-end application, but rather accessed through an ASP.NET Core API gateway. We are using IdentityServer4 for the OpenID Connect server. I have been able to setup the UseJwtBearerAuthentication middleware to have API gateway validate the JWT bearer token (access_token) against IdentityServer4. I would like to be able to have the API gateway inject the id_token, based on the access_token, into the requests made to the back-end services that may need to know the end-user.
Is there a way to configure the JWT middleware to retrieve the id_token when validation the access_token or do I need to manually call the OpenID Connect server in the API gateway?
You don't use id_tokens at APIs - they are for clients.
If you want to have access to certain identity claims, either include them in the access token (by configuring the ScopeClaims on the resource scope), or use the access token to contact the userinfo endoint which in turn will return the identity claims.
The JWT middleware performs standalone verification, it does not contact the identity server to verify or retrieve anything. You'll have to make an additional call.