I implemented OpenIddict with ASP.NET Identity as a separate auth server and I use the client credentials and password flows. I also have a web api project as the resource server.
The resource server is deployed in IIS and needs to authenticate domain users as well as end users. All controllers have the [Authorize] attribute and the actions have a custom authentication filter inheriting from ActionFilterAttribute with which I check for permissions against the db. The resource server has integrated windows authentication.
Currently at this stage of the development I cannot use ADFS or AAD.
Domain users access the resource server using a Winforms app in which they pass their network credentials. End users have websites and native apps and will/should use password flow to get an access token.
So, my question is:
Should I have an endpoint with [Authorize] in the auth server with which the domain users can authenticate with? In this case I would also need to use integrated windows authentication (which I'd rather like to avoid).
And once the domain user is authenticated, should I use the client credentials flow to acquire an access token? Domain users do not need to be saved in ASP.NET Identity. End users will use password flow.
Is this the correct way to handle both Windows Authenication and OpenId?
Related
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.
I have an existing system and want to utilize Auth0(still considering).
Context:
I have my own login screen, which is quite dynamic(white labeled) per client. So I dont want to use Auth0 login screen.
I have my own user and tenant database, so dont want to use Auth0 user database for now.
So the idea is to validate the user credentials after login on my backend and create access token to return to client side.
I want that access token to be validated by Auth0.
Questions:
1) Probably most important question. Should go with Auth0 or just stick with native jwt's
2) Is there a way I can create a valid access token in my backend which can be validated by Auth0.
Stack:
I am using vue.js as my front-end SPA.
I am using .net core as my backend.
Probably most important question. Should go with Auth0 or just stick with native jwt's
That is determined by whether you want to enable the online identity provider's features like Single Sign-On . If not , just keep using the current one since you don't need the Auth0 user database .
Is there a way I can create a valid access token in my backend which can be validated by Auth0.
Since your scenario is collect username and password in front-end application , and pass to backend .net application to validate credential and create token . You can implement the Resource Owner Password Grant in Auth0 to create access token for accessing resource which protected by Auth0, but as document shows :
You should use this flow only if the following apply:
The application is absolutely trusted with the user's credentials. For Single-Page Apps and Native/Mobile Apps, we recommend using web flows instead.
Using a redirect-based flow is not possible. If this is not the case and redirects are possible in your application, you should use the Authorization Code Flow instead.
So that it's not recommended in your scenario . If you need the features like SSO and want to use Auth0 , it is recommended to directly use Auth0 in vue application to manage your users and roles :
https://auth0.com/docs/quickstart/spa/vuejs/01-login
After login with Auth0 , you can map the user to local database user for specific management if needed .
Another way is using Client Credential flow . For this scenario, typical authentication schemes like username + password or social logins don't make sense. Instead, M2M apps use the Client Credentials Flow , your backend app will authenticates and authorizes the app rather than a user. It's not suitable if you want to acquire access token for specific user to access protected resource .
I'm trying to setup an application to validate identity using Azure AD and acquire a token to allow access to a secure api. The front end application is written in angular and allows anonymous access. What can I use to access AAD authenticate and return an access token?
This will be an angular 6+ UI that is communicating to a secure .Net api using Azure AD for authentication. I have done a couple days research and everything points to a user logging in to authenticate using the login page. I need it to be by app and open the login page. I tried a couple examples where it utilized authentication/authorization and that didn't work because the app needs to authorization the user to talk to the api. I have seen where people were using Microsoft graph but once again it was user based and they were redirected to an azure login. I am looking for a solution that will allow me to setup an account in azure ad and authenticate the app on start to get an access token to allow communication to my secure api. If I have missed something somewhere in my research and test attempts let me know. This is my first Azure AD auth attempt and I feel like I am missing something for application authorization.
The problem is an Angular app is what we call a public client.
It cannot hold secrets and thus cannot prove its identity.
So, only user-based authentication flows should be used by public clients.
Confidential clients on the other hand can hold secrets as they run on servers that you control.
So for example, a back-end Web application or API would be a confidential client.
Those can use the client credentials flow to acquire access tokens and call APIs as themselves without a user being involved.
There is a bit of a fundamental issue in your question.
Your API requires authentication, but you want functionality to be available to anonymous users.
So you want to bypass authentication.
If you really want to bypass authentication for parts of the API, you could just make those endpoints available anonymously without a token.
I'm building a SPA (angular) with a back-end api (asp.net core), both are build and belong to the same party.
I would like to use jwt authentication instead of cookie based authentication, because both sides - the back-end and the front-end spa - are owned by the same party I'm thinking to use the OAuth Resource Owner Password Grant flow and there shouldn't be any problem exposing the users credentials to the web app.
After searching on the web, I see a lot that it's not recommended to use this flow, but why should I implement any OpenId Connect flow with a redirection to the auth server if the web client belongs to same party of the api and the auth server?
The problem in your case is not so much in exposing the credentials to the Client since as you mention, all components in the flow are controlled by the same party.
Yet there are advantages to redirection as doing so separates the authentication method and means from the Client itself. And that enables e.g.:
a change of authentication mechanism or an upgrade to multi-factor (or some other advanced form of) authentication without impacting the Client(s)
SSO across different web applications
granular per-Client permissions
easy access revocation without having to change the user's password
less confusion for end-users as to which applications(s)/Client(s) they can trust with their credentials
Basically I just want to know how does StackExchange's single signon system work?
In the SE network you need to login only once in one of the websites to be automatically logged in to the other sites upon visiting.
How should I implement such a feature in my own network of sites?
I assume it uses the cookie which resides on the user's browser and then authenticates it with the originating site. If it is legit then it logs the user in automatically.
You have to implement SAML or oauth2 to allow sso on your network.
In case of SAML your child websites will be service providers or resource servers.
While you need to setup and identity provider.
The sequence of events will be like this.
1. User hits a url of songs website, this site is resource server and does not handle authentication.
2.To authenticate resource server will construct a SAML authrequest and redirects to identity provider after signing it.
Idp verifies the signature after receiving authrequest.
3. User will be presented with a login form, user has to end login credentials.
4. After user authentication idp will generate a SAMl token and redirect back to resource server.
5. Resource server will extract identity information from SAML token, resource server will login the user with session or cookie.
Depends upon which technology you are working in i have implemented it in php using simplesamlphp.