Using Spotify authentication with Blazor WASM - asp.net-core

I want to login an user optional with Spotify (only) as identity provider in asp.net core from an Blazor WASM page.
I use that example to configure the server. I also searched in the Microsoft Docs, but I didn't found an example to start an authentication request. Currently I'm not redirected to Spotify OAuth login page.
I don't know how I start the login flow. Is there a "default" route to start the ASP.NET Core login flow? Or is there any good tutorial to start that?
The Application should have an login button and I need the token on server side and on client side. I would prefer to do the authentication on the server side, because i don't want to have the client secret on the client side.
Are there any best practices to solve this problem?

From you server controller you can call the ChallengeAsync method to start the configured authentication schema.
If you are requesting a token from a SPA application (like Blazor WASM), then use Authorization Code With PKCE. PKCE does not require a client secret so it is safe to request if from the client side application.
Otherwise I would use Authorization Code Flow and exchange the code for the token on the server application. Basically the sample you linked does this by utilizing a AspNet.Security.OAuth.Spotify nuget packege.
(Spotify uses oauth 2. I would recommend to pick the authentication flow that suits your use case. For example the client secret should not be in any SPA application.)
There is a good summary table on Spotify docs.

Related

How can I integrate Google and Microsoft authentication with JWT Token in Blazor Webassembly?

I have a Blazor Webassembly app (Asp Net Core hosted).
I secured my app using JWT Token. Client makes a request to Server and if the request is valid, server sends JWT Token to client and token is saved in local storage. Client reads the token in storage and this way authentication is handled.
I followed the following practice from Chris Sainty :
https://chrissainty.com/securing-your-blazor-apps-authentication-with-clientside-blazor-using-webapi-aspnet-core-identity/
Now I want to enable users to login app with their Google or Microsoft accounts. What would be the best approach for this?
I tried Google and Microsoft authentication on server-side but I couldn't pass the token to client. (because there is no request from client..)
Your response exist in these links:
Google Authentication by OIDC
Microsoft Account using MSAL
But the details requires studying related Service and js files.
You can study sources of Remote Authentication Service in Github for both oidc and msal in following sites:
Web Assembly Authentication Service
Personally I suggest you to use Microsoft Account which also allow authentication through Google and other providers too. Altough oidc provider is more oidc than msal approach. Microsot implemented Code Authorization flow in msal while Google uses implicit token flow (do not forget that these happen in client side). There is two different js files for implementing the underlying requests so I do not think even the combining them work in this way. May be it is better you code it your self by implementing an authentication state provider which uses JS Interop.
You also can see following example which may help you by DotNet guys:
Example of Web Assembly

Consume JWT token in asp.net core web application

In one of my project need to consume JWT token from asp.net core web application. My trial project is on github https://github.com/SapanPatibandha/JWTAuthentication
This has one server JWTAuthentication which is generating jwt token base on username and password.
Second component is AnyAPI which method is protected by self verification of JWT.
Third important part and where I have problem is Web application.
Need to create login screen in this application, base on this user detail call login api from JWTAuthentication and use that token for all further use of api from that web application.
I am not sure about middleware configuration and how to store this token on web application.
Thanks
IMO, What you asking for is a journey that need some investigating time, that's not what could be answered shortly, so... I'm gonna make this as compact as possible
What you're doing in the repo is hand-generate and validate Jwt Token. If that's required, investigate these stuff:
Generating Jwt on central identity provider server (which you currently have)
Validate Jwt on api resource (which you currently comment that out)
On application(seems like you make use of classic MVC or razor page), create login form that use ajax to get Jwt from identity provider server, store it on client side (browser), then attach it with every request that make use of AnyAPI, by cookie or header or something you saw reasonable. Or if you choose to save the token on Server side, implement your own session-Jwt mapping logic(Actually, some kind of Js SPA would be more suitable for this kind of approach).
Another approach would be implement a more proper Oauth implementation. I consider 2 most widely acknowledged in .net ecosystem would be Identity Server and OpenIdDict. Highly recommend to check them out.

How to send a JWT from my back-end server to my front-end after Google OAuth2 Authorization flow

I am creating an application with a React front-end and a Java Spring Boot back-end.
My login flow looks like this:
A user clicks on login on the front end
User is redirected to the Google Oauth authorization endpoint on my server
OAuth 2.0 Authorization flow happens: User is redirected to Google and logs in. Google interacts with my server first exchanging an authorization code and then a JWT access token. My server now has the JWT access token for the user.
ISSUE: I now need to redirect the JWT token to my React front-end so that the token can be saved and used every time the user wants to request access to a protected resource on my server.
Is there now an industry standard/best practice for redirecting the token to my React front-end from the server?
There are similar questions on this subject on Stack Overflow, however they are at least 3 years old, e.g. How to provide frontend with JSON web token after server authentication?
Since then the implicit flow has been deprecated, storing JWTs in local storage is no longer recommended, and https://datatracker.ietf.org/doc/html/rfc6750 explicitly discourages passing bearer tokens to the front end in a redirect URL.
I was wondering if anyone knows of an up to date solution for this problem.
There's a draft IETF BCP for OAuth 2.0 for Browser-Based Apps - see here. Basically, it's very similar to native mobile apps using authorization code with PKCE (proof key for code exchange).
FWIW I agree implicit flow shouldn't be used, but IMO you shouldn't be using authorization code flow without PKCE, as this flow is for server side rendered web apps.
EDIT - Auth0 (one of the most popular CIAM solutions on the market) docs say the same thing - see here.
If the Client is a Single-Page App (SPA), an application running in a
browser using a scripting language like JavaScript, there are two
grant options: the Authorization Code Flow with Proof Key for Code
Exchange (PKCE) and the Implicit Flow with Form Post. For most cases,
we recommend using the Authorization Code Flow with PKCE...
Don't.
You seem to mix 2 issues here.
First, you would like to use OIDC for authentication in your SPA. For this you would use OIDC Implicit Flow or Authorization Code Flow with PKCE.
Second, you would like to delegate authentication to google instead of doing it yourself. Basically this is known as federation - you trust external Identity Provider.
The full-blown version would be to setup your own Identity-Provider server (like e.g. keycloak) and configure federation to google there. Your SPA would initiate OIDC against your Identity Provider and wouldn't even know that google did the authentication. You could also easily add further Identity Providers (e.g. facebook) if necessary.
An easier workaround would be to initiate OIDC login from your SPA directly to Google. This way your SPA would receive token directly from google and you would need to protect your own backend as a resource-server accepting and validating those tokens. Adding further Identity-Providers like facebook would be a challenge.

Implementing OAuth2/OIDC for VueJS SPA and asp.net core 3.1

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.

ASP.NET Core Authentication via Google Sign In with REST API in between

I have a requirement to authenticate ASP.NET Core App via Google Sign In, but a Web API between client app (i.e. ASP.NET Core app) and Google sign in... I know it sounds confusing, so let me explain it with diagrams.
Here is the typical way to include google sign-in button and get user authenticated via their google credentials, It works perfectly fine
Step 1: First, create a new app on google identity developer portal, generate ClientId, ClientSecret and specify redirect_url like : https://yoursite.com/signin-google.
Step 2: In the Startup.cs class of ASP.NET Core project, Use AddGoogle as authentication middleware and it works perfectly fine.
Including diagram below for your understanding:
And here is the proposed flow. With a REST API in between client and google sign in. Question is, how do I authenticate client ?
From what I understand, you want your Client Application to invoke the REST Service on behalf of the user. The REST service needs assurance that both the Client and the User are authenticated.
We have achieved this using the OpenID Connect Hybrid flow. The bad news is that we had to add another service to the solution to achieve this.
How this differs from your proposed solution is this:
You must have your own identity service, and this must know of the existence of the REST service, the Client Application, and the User Identity.
The Client Application redirects the user to authenticate with the Identity Service (which further on redirects the user to authenticate with Google)
Identity Server provides the client application with an ID token for the user, and also a code which can be exchange for an Access Token
The client application requests the Access Token. This Access Token will authenticate both the client and the user
The client application then authenticates using this access token when invoking the REST Service
The REST Service issues a one-off request to Identity Server for the signature keys, and uses these keys to validate the access token.
We happened to use IdentityServer4 when implementing the Identity Server, but the protocol exists independently of any one implementation.