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"
Related
I'm building an ASP.NET Core application and using FusionAuth as my authentication server. I'm trying to implement this authorization grant workflow, with an SPA using JWT bearer tokens. To summarize, once the user authenticates with FusionAuth, the frontend is supposed to redirect to the backend server with an authorization code. My backend server then needs to receive this code at a special endpoint. Inside this endpoint it will perform a call to FusionAuth again, but this time with the client secret which only the server will possess. In turn, FusionAuth will send back an authorization token in the form of a JWT and a refresh token, which my server then needs to return back to the frontend.
I've looked at the .AddOAuth method, and having read the code it seems capable of performing the token exchange. However, it also has a lot of logic involving challenges and login/logout. This makes me think it's supposed to be used for cookie-based server-side authentication, like you would find with Razor pages.
All I want to do is set up my server to be this authentication intermediary. It looks like .AddOAuth() might do this for me, but it may not be intended for this purpose. I can't find any examples of folks using .AddJwt(...) and .AddOAuth(...) in conjunction. Is there a mechanism in ASP.NET Core that performs the token exchange?
Have you tried using IdentityModel? It's not part of ASP.NET Core, but it is open source. I found it useful when implementing the authorization code grant in ASP.NET core.
Here is some documentation that may be helpful:
https://identitymodel.readthedocs.io/en/latest/aspnetcore/web.html
The short answer is yes - see Introduction to Identity on Asp.NET CORE. There are lots of flavors of OAuth 2, which means it can be configured in many ways. You will need to read the docs.
Context
I am trying to write some integration tests that verify correctness of my RESTful Web API service (.NET Core-based).
To make requests that mimic the user's browser requests I'd need to configure an HttpClient's headers to include Authorization: Bearer {test-user-1-bearer-token}.
Problem
My issue is that I can not find a way to programmatically retrieve the bearer token(s) for the test user(s) I created by hand.
What I tried
According to my research of the Auth0 Architecture Scenarios the only one that could work for me is called Server Application + API.
That scenario relies on retrieving an access token for the testing Application (not a bearer token for a user the code is trying to impersonate).
As far as I understand, this prevents me from having multiple test accounts, which I need to have to be able to test complex, multi-user interaction scenarios around my Web API.
Alternative approach
Instead of using a real production-ready Authentication middleware, I could use a custom middleware when running the service instance for testing.
An environment variable, for example, could drive the decision about which AuthN middleware to enable.
That custom middleware could rely on a non-JWT token source (e.g. custom HTTP Header) to bypass the Auth0 authentication. 🤔
It would be nice to be able to test with Auth0 playing its role, however.
Ugh
I suspect that my question is off-topic because I'm not providing code.
Hopefully, I at least get some answers or comments that give me a clue.
For integration tests you could check if your auth service supports Resource Owner Password Validation flow or Client Credentials flow - it would be easier to obtain access token.
If you still going to do it with Implicit flow - there's a similar question answered - https://devforum.okta.com/t/unit-testing-and-implicit-flow/1210/3. You would need to change from Okta auth service to yours.
P.s.
That scenario relies on retrieving an access token for the testing Application (not a bearer token for a user the code is trying to impersonate)
Bearer token is an access tokens. No matter who bears it, testing app or end user.
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'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.
I have a Web API application and I've understood OAuth would be the standard security model for APIs where an Authentication Server would become responsible to generate Authorization Tokens so that the user can send to our server and consume the services.
I'm very new to this but I understand the roles involved:
Resource Owner
Client
Resource Server
Authorization Server
But what is OAuth exactly in practice, not in theory? Is it a .NET library? Is it a service provided by a separate Company? Is it something I can configure on my local development machine and see how it works?
How to get started with OAuth to secure a Web API application?
OAuth is a protocol; the current version is OAuth 2.0. More to your question, that link lists several implementations of the protocol in various technologies. For use with the .NET Web API you're probably interested in DotNetOpenAuth which provides implementations of both OAuth 1 and OAuth 2.
I'm using DotNetOpenAuth in an app I'm working on now to secure a .NET Web API. I've got an OAuth2Handler which extends DelegatingHandler which is inserted into the Web API pipeline before incoming requests reach any controllers. OAuth2Handler does the following:
Instantiates a DotNetOpenAuth ResourceServer
Calls ResourceServer.GetPrincipal() which reads and decrypts an access
token (issued elsewhere by the AuthorizationServer and returns an
OAuthPrincipal (In my case I'm reading additional data that the DotNetOpenAuth implementation allows you to pass and creating a ClaimsPrincipal.)
Assigning the IPrincipal containing the user information read from the access token to the User property of the thread and current HTTP context so it is available from the ApiController.User property in the service controllers: httpContext.User = Thread.CurrentPrincipal = principal;
Honestly, getting this all working (e.g. setting up the authorization server, resource server, certificates, etc.) isn't trivial. Unfortunately there didn't seem to be a good guide on the DotNetOpenAuth site. Here's a few other tasks you'll have ahead of you if you go this route:
Implement IAuthorizationServer - This is the interface provided by
DotNetOpenAuth that allows you to plug in to the library and use
their implementation to issue OAuth2 access tokens. You'll also need to implement INonceStore and ICryptoKeyStore which I did using an EntityFramework context for storage.
Configure Certificates - The AuthorizationServer and ResourceServer each use certificates to encrypt/decrypt the access token ensuring they are only accessible to each other. I built some custom configuration so I could manage this configuration in the web.config files of my authorization server app and my Web API services (resource server).
Manage Refresh Token - When first requesting an access token from the authorization server you'll get back (depending on your configuration) both an OAuth2 refresh token and an access token. The services use the access token which should be short-lived. The refresh token is used to get more access tokens. The refresh token should be kept secret (whatever that means in your scenario). For me it means the refresh token is never exposed to client-side javascript in my web app.
I hope that helps give you a high level idea of how to get started with OAuth and .NET Web API. Here's a blog post demonstrating some of these steps. This SO answer gives a few more high level details of the client side of the picture.
(The DotNetOpenAuth online docs appear to be down right now... sorry for no links to them; Apparently it has happened before).