I've been tasked with enabling authentication and authorization for our project's api. The main goal is to protect the methods from misuse, however we also need to enable a developer from another company to call the methods in their code.
Being new to authentication and authorization I'm overwhelmed with the many different options available for .NET etc. Some techniques look promising until you read that they pass credentials in plain text (basic auth?) or have other issues etc... I'm just looking for a reliable and safe approach.
I'm using IIS to host the web api, and I have seen that one such option is to authenticate at the 'host level'. My supervisor has mentioned this is the preferred approach.
I have looked at many threads and videos regarding authenticating in IIS. From what I can work out, such a solution alerts the user that a certain action requires authentication and to enter their credentials.
My issues are as follows:
Given the other developer is not a member of our domain, how can they authenticate using their (windows?) credentials. Is there an alternative to windows authentication?
How will requiring authorization on certain api actions impact the function of the site normally? I.e. will I have to pass valid credentials to the api in my code, for each request?
Overall I'm just a bit uncertain on how this all works and I appreciate any advice given.
Related
There are 2 WebApi Projects on different servers. One of these servers (WebApi-A) has OAuth2 authentication workflow setup with Authorization Server and all.
The another WebApi project (WebApi-B) has an end point that I would like to Authenticate through [Authorize] attribute. I don't want have a new authorization server but to utilize (WebApi-A's) authentication process just to validate the token.
From what I understand if the machine-key is same across these server. We can essentially replicate the authentication process from WebApi-A in WebApi-B without having to call WebApi-A at all.
How do I achieve this?
You could, in theory, pass through the JWT token and if your OAuth setup uses the same client secret and data store it should just work. You would have to ensure that you add the JTW token when requesting and to use some distributed cache to verify.
I would rather ask whether or not you should rather create a gateway that can handle and authenticate the requests and delegate them to the separate APIs? This feels like an identity server (http://docs.identityserver.io/en/latest/topics/apis.html) would solve your problem. Anything you do other than moving the authentication from web api A would just be a stopgap.
Duplicating the setup could work but that will mean that you have to now maintain it in two places. So I agree that doing that is less than ideal.
This is a great article that may aid you:
https://www.scottbrady91.com/OAuth/Delegation-Patterns-for-OAuth-20
This will have a lengthy answer so I will just leave you this diagram showing multiple Resource Server, Client, and a separate Authorization Server
Taken from this article Single sign-on across multiple applications (part II) which I hope could get you started.
you can use your token when login in web api and then you add the token to the header "Authorization" with bearer "your token"
Basically, I have a homework assignment which involves me creating a MVC app in Asp.Net (the standard version, not Core). I need to provide authentication using jwt, but i have to use a separate authentication server, so the token creation and validation are delegated to that server, and if a server like that already exists (perhaps a facebook or twitter authentication server using jwt), i should use it rather than create my own. I am not sure if there is a jwt authentication server which I could use, and I don't know what is the best way to handle jwt tokens, for example if i have a form that submits stuff to a controller action, how to place a jwt token in the request. Any help on this would be much appreciated!
As this is a homework assignment I'm going to try and provide a jumping off point rather than provide code samples or anything.
A JWT can be issued from another authority and used within your own application provided your application is set up to use that authority. For example, in house we use AWS Cognito to store our users, and in each of our web applications we specify that our JWT tokens are being issued by that Cognito user pool.
I've had a quick look around online for any issuers that may provide this service for free, and found the following blog post for Auth0 which boasts being able to support up to 7000 users for free (there may be hidden costs, I haven't looked into it fully)
The tutorial in the blog post seems to follow a .Net standard rather than a core implementation. Hopefully you find this useful and good luck with your assignment!
I'm working on building a series of micro-services using Aspnet Core. A mobile application, desktop application and web-application will consume the services over Http REST APIs.
For user auth, I'm utilizing the Aspnet Core Identity platform, but I'm exposing the creation of user accounts via a REST API. The clients make a REST call with the credential information and my API uses the Microsoft Identity APIs to provision the user. The user would be authorized to hit the individual resource servers with an auth server using IdentityServer4.
I have two questions that I've not been able to find clear guidance on from a security stand-point. Should the Aspnet Core project that utilizes Microsoft Identity for user creation be in an independent Aspnet Core project from the project that handles auth via IdentityServer4? Are there downsides do separating the two out that I need to consider?
The Microsoft Identity API has template and Razor Views that can be used to handle the auth from a server-side perspective, including redirects on account creation or sign-in etc. If I'm doing everything via SPA or Client-side native apps, is there anything wrong with just providing a POST API that accepts the user information, creates the account via UserManager<T> and returns the UserId?
I want to provide a dedicated sign-in page, similar to FB/Google/Twitter etc for Auth to happen across any app that wants to authorize a user for my services. I don't typically see account creation as part of the OAuth process though. Is it typical that you would allow for redirects to an account creation page, that redirects back to a client upon successful account creation or is that process typically just used for Auth via OAuth flows?
I would suggest to consider using one service for IDS4 and ASP.NET Identity since they can be integrated and give you the full functionality you're looking for(auth, and users management).
IDS4 has examples and good documentations regarding that.
To me, I think separating them would be an over engineering.
one example: when IDS4 generate access token for a user, you should get claims, roles and validate username and password, all of that are stored in ASP.NET Identity.
So for more details you can check the docs of Identity Server 4: http://docs.identityserver.io/en/latest/quickstarts/0_overview.html
or it's my pleasure to check my little blog post that I tried to give some more detailed and step by step.
https://feras.blog/how-to-use-asp-net-identity-and-identityserver4-in-your-solution/
Start with IDS4 link because it might be enough :)
The main point when thinking about security management UI is how to secure that UI. And the most safe approach for today is cookie-based auth with same-site cookie (the way, MVC uses by default). Consider that when and if selecting serverless SPA pattern. For management purposes-app having strict backend is much more secure than token-based access to distributed api-s.
Regarding the application hosting, #VidmantasBlazevicius is absolutely right, there is no the only strategy: hosting all the services in one app is simpler, so it better fit lo to middle loaded systems. But with raise of the number of users and authentication requests, you might want to scale, and separating management UI from authentication is one of the ways to handle that.
We are building a web application that also includes webAPI's. These WebAPIs needs to be exposed to other applications as well (other internal application on different subDomain or 3rd party application). We are thinking of using OpenId Connect, so that not only we will be able to give access_token but also id_token for authentication.
Now the question is 'Should my main application also use openId connect' for authentication/authorization. I am not in favor of this. As per my understanding, only external applications should use openid connect to use main application's resources. And internal applications (main as well as application on different sub-domain) can work with regular cookie based authentication.
For instance, main application is MyWebApp.com (this includes webapi as well). Other internal applications are maps.MyWebApp.com, admin.MyWebApp.com, payroll.MyWebApp.com.
Other 3rd party application could be OtherWebApp.com.
Please suggest.
"Should my main application also use openid connect?"
Advantages
- paves the way for single sign on
- modularizes your authentication so you're not implementing different authentication solutions.
- you have the option of using the same Web api from your main app. (although you could just use the oauth2 client credentials flow and simply skip the openid connect authentication part)
Disadvantages
- if you only had one client app then this could be overkill
- you're adding complexity to the app by making it depend on an authentication server app (but modularizing has advantages too)
I don't know your scenario completely but I'm inclined to say yes. Although, I'd definitely turn off the consent screen from oauth2 for your trusted main app. If you don't use openid connect for authentication, it shouldn't be too hard to convert your main app to use it later
I am in the processing of developing a web application which will integrate directly with a Google Calendar associated with a specific Google account. The account being accessed by the Google Data API is not likely to change, so I'm unsure what the most appropriate account authentication method is going to be.
I've reviewed the options avilable and it would seem that AuthSub and OAuth are inappropriate as I will not be logging users into their own account- only displaying and updating a fixed account. The other options available are ClientLogin and Gadgets authentication. Of all of them, ClientLogin seems the best fit, but the documentation states that it is intended for installed applications. While the web application I am developing is not specifically an installed application, it closely mirrors one in this scenario- which is why I think ClientLogin makes the most sense.
Which Google authentication option would be the best fit in this scenario?
After reading http://code.google.com/apis/gdata/docs/auth/overview.html it seems to me that OAuth is the most secure way to achieve your goals. Google recommends OAuth or AuthSub over ClientLogin for Web Applications. In addition using OAuth and AuthSub prevents your application from ever having control of the users email and password meaning you dont need to take the extra steps to protect and update the information. Between OAuth and AuthSub, OAuth is more universally adopted, and more secure due to the fact that requests are signed. Hope that helps.
EDIT: So I misunderstood exactly what your application was doing, if you are only using your google account any method of authentication is probably fine, that said google recommends OAuth or AuthSub for web apps. However the important thing to find out about OAuth and AuthSub is what the life of the token is. If there is no way to make the token last for a long time (months, years) then I would try to use ClientLogin, because then your application will always be able to login to the account. As a side note however for security I would recommend you NOT use your primary google account for the application instead create a second account and simply share the calendar with your primary account, that way if you application was compromised you would not lose your primary google account.