I am currently diving into Identity Server 4 and working on a local project for my own learning.
I currently have a login page located within the Identity Server 4 project which allows the user to login, this works perfectly fine.
The question I have is, can I make a REST API request passing in username and password to authenticate the user instead of using the login page located within the Identity Server project? this may sound a very simple question for some, but my knowledge on this is very limited at present.
You are talking about Resource owner password flow.
It allows you to request access token with username/password pair.
After that you can use access token in a usual way to access your API.
Link above says that
The spec recommends using the resource owner password grant only for “trusted” (or legacy) applications.
Related
I am working on a .net MVC and web API project and using active directory to authenticate users to API, on authentication, a code is being returned from AD and I have to exchange the code to obtain a token and use that token to call the API, the question is why is the code returned and why do I have to exchange it for the token? can I directly obtain a token?
This is all because of security reasons.
OAuth 2.0 wanted to meet these two criteria:
All developers will not have an SSL enabled server and you should allow them to use non-HTTPS redirect URI
You don't want hackers to be able to steal access/refresh tokens by intercepting requests.
Since the Authorization Code grant has the extra step of exchanging the authorization code for the access token, it provides an additional layer of security not present in the Implicit grant type.
According to Nate Barbettini we want the extra step of exchanging the authentication code for the access token, because the authentication code can be used in the front channel (less secure), and the access token can be used in the back channel (more secure).
Thus, the security benefit is that the access token isn't exposed to the browser, and thus cannot be intercepted/grabbed from a browser. We trust the web server more, which communicates via back channels. The access token, which is secret, can then remain on the web server, and not be exposed to the browser (i.e. front channels).
For more information, watch this fantastic video:
OAuth 2.0 and OpenID Connect (in plain English) https://youtu.be/996OiexHze0?t=26m30s (Start 26 mins)
Your question isn't really specific to Azure AD, and is more about the OAuth flow and why it is used.
The flow seems a bit complex, and well, it is, but there are reasons for all the things it does.
I encourage you to use authorization code flow instead of other approaches.
It has many advantages:
Your app will never see the user's password
The user cannot see your app's client secret
The user cannot see your app's access tokens (and neither can a man-in-the-middle attacker)
You get a refresh token that you can use to get new tokens whenever needed (you do need to specify the offline_access scope for this though)
The user can go through multi-factor authentication, federated authentication with ADFS etc., and your app doesn't need to care about that
Alternative flows and their downsides:
Implicit flow
Gives you a token directly without the code exchange
There is no refresh token
Mainly used in Single Page Apps, where refresh is done using a hidden iframe, but that depends on the user's session remaining active
If you use this outside a SPA, you can't really refresh the token, requiring the user to login again every hour
User can see and take your app's access tokens
Client credentials flow
Instead of accessing the API as a user, you access it as the app itself
Some APIs do not support this approach and require you to make calls on behalf of a user
This doesn't allow you to authenticate a user
Application permissions are needed to use this flow, which usually give very broad access to the entire organization
The upside of this flow is that it is very simple
Resource Owner Password Credentials flow
Do not use this flow
HTTP request to token endpoint with app + user credentials
Exposes user password to your app (!)
Does not work if user has MFA, expired password etc.
I've got a user authenticated via IdS4, along with a few claims and a role, now I'm lost about what to with it. The general flow for the user is: Go to my site, log in redirects to IdS4 server. They enter their username/password, and redirect back to my site, along with cookies set.
I've not seen much beyond authentication in the tutorials I've found.
Should/How do I persist the user? Should I set up Identity on my MVC site? I'm just looking for a general idea, I think I can figure out the specifics, at this point my general Googling hasn't turned up much.
Thank you.
You can add ASP.Net Identity to manage users in your client MVC application , or directly use EF Core to store users in database without ASP.Net Identity .
But the problem is why you want to perisit or manage users in your client application ? You are using Identity Server to do authentication and IDS will connect the database/configration file to validate user and fill user claims , if you want to manage users/roles , you can add apis(CURD operations to user database) as protected resource , and your client app acquire access token to access that apis to perform user management . So that user management operations are share to clients which have permission to get api's access token . But if you want to manage specific users which only available to one client , you can mix asp.net identity and IDS4 authentication in client app .
I am having some issues of finding forums/tutorials/examples on how to fully authenticate an angular app with Azure Active Directory. So in short, I need to log in to the user via angular 8 and I am using the https://www.npmjs.com/package/#azure/msal-angular library which I found really good and easy. I am retrieving the token id and the user after login. The issue is, that I need to add that user to the Database because I have like a role management system which I need to add the user in the aspnet users db. I need to call an api which needs to authenticate that the user is real from .net side and then add the user to the aspnet users db. If he's already existing there so it just need to authenticate him and create a token. I need to know example of .net on how to populate the User.Identy with the user. I am sending the api 2 headers, Authorization which is the bearer token id and access token. Can someone please help?
assuming you're using aspnet core, you just need a middleware which will validate your JWT token acquired from the front end, and check if the user / token are valid (and also populate the User.Identity for you).
More info: https://github.com/aspnet/AspNetCore/tree/master/src/Azure/AzureAD/samples/AzureADSample
EDIT:
for asp.net mvc (non core), you'll do the same approach:
https://www.c-sharpcorner.com/article/azure-ad-authentication-for-mvc-web-application/
I'm about to start working on an ASP.NET (C#) website project which requires users to authenticate and I've run into a bit of a design issue. I am required to use a SQL Server database to store the web app's data (to include user's login data), but all of the information I've found regarding ASP.NET and authentication uses Windows Authentication.
Now of course I could just write the code to query the database and check the users input against the database to see if the username/password exists (the current plan), but then how do I set the state of the session to authenticated along with other data (such as a user ID) so that the site can give the user only their data?
First, read more on Forms Authentication. You couldn't have really missed that (could you?) but it's the other major authentication mechanism that doesn't involve Windows accounts, instead the session is maintained with the help of a cookie that stores the user name together with any other so called user data (could be user ID or whatever else).
Second, the Membership/Role Provider mechanism is available for like 10 years - and it gives you an abstraction you implement on your own. The abstraction is about storing users/passwords/roles. The Membership/Role Provider is nowadays slowly replaced with the Identity 2.0 framework and you are free to choose the olderone or try the newer.
These two together, Forms Authentication and Membership/Role Provider, make a foundation of what you need.
The basic flow is as follows:
users request various resources ("pages")
some resources are guarded from anonymous access and require authentication/authorization
the Forms Authentication module redirects requests to such resources to a login page (login view)
in the login page you use the Membership/Role Provider to verify user and issue a Forms cookie
you redirect back
The Forms authentication module now picks the cookie upon every request and recreates the identity so that the user is authenticated when your server code is about to run.
I am looking for single sign on for my application which is built on javascript (no server side language).
Requirement:
Agent log in to Windows (user integrated to Active directory)
Open my web page
Based on who logged in to windows, my application goes to AD and pull some user
specify data (eg email, phone)
How shall I go about it?
As per my understanding I will require ADFS for this.
So:
User goes to my web page
My web page calls some Web services or web application (which is build on c#)
That will authenticate against AD FS and get claim
Either get phone number and email in claim or get username and query AD for phone and email
Return the data to my web page (build on javascript)
It seems there something wrong in my understanding!!
Please suggest more appropriate solution based on my requirement
Frankly, I can't think of a way to make it work without a server side processing. This is because the ws-federation protocol ADFS uses is not just about returning claims.
It is about returing a SAML token. The token contains claims but what is most important about it is that it is signed using the XMLDsig. How are you going to validate the token is a first big question. But there are surely external libraries that allow that.
But then, such authentication can easily be bypassed by modifying scripts in the browser. This is because the ws-federation stops where you get the token and then it is up to you to exchange the token for the actual identity. And this won't work when processed only at the client side.
ADFS 3 does not support the OAuth2 implicit profile, which would be an option, but still you would need to verify the token on the server to avoid session fixation.
You can setup something like AuthorizationServer that supports Oauth2/OpenID Connect implicit profile
http://leastprivilege.com/2013/09/19/adding-oauth2-to-adfs-and-thus-bridging-the-gap-between-modern-applications-and-enterprise-back-ends/
Another option is to use something like Auth0 (Disclaimer: I work for Auth0) which also supports OAuth2/OpenID Connect implciit profile. In that case you wouldn't need ADFS, there is a connector/agent that you install on your network that does not require opening firewalls or anything and it supports implicit profile that is suited to JavaScript apps. This is an example of a single page app tutorial (if you create an account it will tailor the doc with your credentials):
https://docs.auth0.com/singlepageapp-tutorial