I'm in a scenario where there is a Blazor app that has to be protected.
This app need a login on local user store or external auth on google or facebook or MS.
There is a asp.net core project that expose all the API for this Blazor app.
All API are protected [Authorize] and this api project implement also the login api that generate the JWT token.
Whit a local login, the login page was on the Blazor app that called login api, managed the response retriving JWT and store in the local storage. For each request Blazor app sent JWT token to authorized api.
How to manage External Authentication in this case? Is Blazor app that has to generate the call to Google, facebook,... and then the google callback will call the api project to generate the jwt ?
I cannot understand how to let the flow work, as api are protected by JWT, and I guess external authentication has to callback the api to generate jwt, but I how to return back to the Blazor app?
I dont' want to use Identity Server 4 , but I could externalize login page on api project.
Related
I have a Blazor Server app which wants to connect to a .Net Core WebApi. The app should send an authentication request and the WebApi returns a JWT containing user data. For any further communication with the WebApi the JWT should be used to authorize against it.
I'd like to ensure that only authenticated users can access the server app. If someone is not authenticated he or she should be redirected to a login page.
Up to now I've used a combination of default Identity with AzureAD authentication.
Is there any option to have a JWT authentication working the same way?
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'm try Auth0 service and I want to build an API where I will be able to give access to some date securely to a mobile app and a SPA.
I build the API following those steps : https://auth0.com/blog/securing-asp-dot-net-core-2-applications-with-jwts/
Then I use the SPA template auth0 offered.
The SPA is working but I don't know how to link it with the API. I don't see where the JWT is handle on the front to make a call to api/books with the bearer token.
I'm new to asp.net core.
I'm trying to create a simple WEB API with asp.net which uses Jwt Token and Google OAuth.
About JWT, I've followed this tutorial and succeeded : https://stormpath.com/blog/token-authentication-asp-net-core
But I don't know how to do my authentication with Google OAuth in my WEB API system. What I think about is :
Because WEB API doesn't have view, a client app (Desktop App, iOS App) will get authentication code and exchange that code for access_token.
Web API receives access_token comes from client, send request to Google to verify the token and do authentication.
My question is :
Is my implementation correct?
How to implement it by code ?
Thank you,
I've created a mvc web application that uses openid to authenticate with Azure Ad and get the claims along with the token. I'm interfacing with Web Api to do the business transactions. The web Api is configured to oauth bearer tokens.
I've created separate oauth clients in Azure Ad for the Web App and Web Api. I'm able to get a token for Web Api from the Mvc Controller using AuthenticationContext to send to request to Web Api. I need to know how I can send the current User Claims as well to the Web Api. The claims in the Web Api are not having the claims of the User from the Web App.
Let me provide a bit more context here. I've created a MVC Web Application and a Web Api layer. The MVC Web App is configured to use OpenID authentication using Azure AD and I've configured the Web Api layer to authorize using OAuth Bearer tokens. The actions in the Web Api layer will be called through ajax requests and the bearer token will be added to the header of each Ajax requests. When the User is authenticated in the Web App, additional claims are added to the User on top of the claims from Azure Ad. I'm able to create a token for the Web Api layer using AuthenticationContext.AcquireToken, but the token for Web Api does not have the User info from the Web App.
I'm taking a wild stab in the dark here, based on what I think is happening.
Claims are attached the user, so theoretically, any claim you add in one place should be available in the other, as long as both applications share the same user datastore. However, claims are loaded at the point of authentication and not dynamically updated. As a result, if you're already logged in to the web application and you add a claim with your Web Api, that claim will not be available on the web application side until the user is re-authenticated.