I'm trying to figure out if this is an anti-pattern or if this is a valid way to do things.
I have an MVC5 web app that accesses a Web API. I manage identity via ASP.NET identity 2 via the MVC app.
I'm trying to figure out how to issue an OAUTH2 bearer token from the MVC app to send to the Web API, and then how to access the claims from the token in the API.
I'm assuming as long as the app and the API share a machine key that I can somehow decrypt the token at the API (correct me if I am wrong), but how do Icorrectly issue a token from the app? Is it fair to assume that I can just use OAuthAuthorizationServerOptions to create a token endpoint on the MVC app, then get the token from here prior to calling the Web API?
All of this makes sense to me, I'm just looking for reassurance that this is the right, or accepted way to do things in this scenario.
Related
Is it recommended or good practice to protect a Web API directly with Open ID Connect or not?
The setup:
Mobile App
Authorization Server (ADFS 4.0)
Web API (ASP.NET Core)
Currently I do the normal OAuth2 "Authorization Code Flow", and then pass the access_code to my Web API in the HTTP Header as "Authorization: Bearer ".
In ASP.NET core I just do the usual
services.AddAuthentication(...).AddJwtBearer(...)
Works fine.
But everyone talks about OAuth2 beeing only "pseudo-authentication" with certain flaws. I want my Users to be a properly authenticated before using my Web API. So it seems like Open ID Connect should be the way to go, aka "real authentication".
But does it actually work to "consume" Open ID Connect authentication in an ASP.NET Core Web API? And if yes, how? And is it good practice? All samples seem to be about Web Sites, not Web APIs.
There is an extension method
services.AddAuthentication(...).AddOpenIdConnect()
But here Implement OpenID connect Authetication in asp.net WEB API they state that "this component is designed for user interactive clients".
What i also don't understand, what would I do with the "id_token" I get from Open ID connect.
Currently i just pass the "access_token" as Bearer.
How do i consume the id_token?
Some clarifications:
The API does not act on behalf of a user (access to company data).
The API already has access to the "data". It does not require any auth workflows for itself nor does it need to pass the users credentials along.
The API needs to know "WHO" the user is, and it has to be done in an modern and good way
That's why I was thinking of OICD with its "real auth" (VS Oauth2-only which is "pseudo").
I basically cannot wrap my head around how the stuff returned from OICD (id_token) will be passed to my Web API.
OIDC is an OAuth workflow. It merely extends OAuth; it is not a replacement for it. APIs are typically authorized either by token or client secret. The difference is simply whether it's acting on behalf of a specific user or not. For example, something like the Facebook API has both workflows for its API, you generally operate with Facebook's API as a client app using the app id and client secret for your app, or you can do user-specific things like create a post on the user's wall given an authorization token.
That authorization token almost invariably comes from an OAuth workflow. Given your stated setup, your mobile app would handle this to get an auth token for the user from your ADFS server. Your API, meanwhile, would actually probably do both. It would communicate both using an assigned client secret and a user auth token, if the mobile app provides it with one.
What I am trying to do is use WebAPI to authenticate both an MVC application and a mobile app using Token based auth. I currently have the MVC application authenticating with the database directly using the standard .NET SignInManager code the VS generates. I have my WebAPI in a different project and will reside in a different website.
I have the mobile app using the API for token based auth. What I am trying to do now is move the MVC app to use this same auth. I am hoping to using the SignInManager as I am now and just change the underlying auth location to the API using tokens. I am doing this to authenticate the user in the MVC application and also using the token from the API to secure the API.
I not sure that this is a good idea or what the best way to accomplish this is. It may be a bad idea. Maybe I should merge the API and MVC applications into the same project? Any feedback or ideas would be great.
If this does not make sense, please let me know.
The idea of a Web Api is the possibility to use a Service with multiple clients, i.e. an Angular Web App a Xamarin Mobile App and a Console App, all of them consuming the services of the API using the same Auth Method, usually Token based, conceptually that is the idea.
Now in your scenario you created a MVC Web App and then a Mobile App but for the mobile app you created also a Web Api, so basically you have two places where you put your Business Logic.
What I would recommend is to move and centralize everything in your Web Api and use that Auth only so in your MVC client project you just store your token as you do in your mobile App.
Currently I have 2 relying parties setup in the same ADFS server; one for my web api and one setup for MVC application. When I get the token for authenticating in MVC app I capture this token to send it to my web api for authentication as well. This token does not work for the web api.
If I specifically make a new call for that relying party(web api) it will work so i think that it is setup correctly in ADFS...
Is there a configuration issue in ADFS not not allow the same token to work for both?
Is this even possible?
Is this the wrong architecture in ADFS?
Should I use one relying party for both apps?
You can use Identity Delegation which helps in scenarios like this where an app calls a service instead of a user.
This similar question has some good resources:
Pass ADFS Token to a Service
I am developing web application which consists of a Silverlight application and a REST API. An optional use case is that the customer may also want to integrate with Salesforce. By "integrate" I mean utilize SSO with Salesforce when logging into my application as well as access data via Salesforce's REST API. The current hurdle I can't seem to get over is that SSO uses WS-Federation while Salesforce's REST API uses OAuth 2.0. What is the best way to being these two authentication mechanisms together?
My knee-jerk reaction was for my Federation Provider STS to acquire an OAuth access token from Salesforce and add it as a claim to the security token received from Salesforce's Identity Provider STS, but I think this might require me to write a custom STS. I'd rather not do that. Is there a better way?
This question is old but comes up often, so ...
There is now information on how to do this here
Configuring-SSO-to-SharePoint
This approach uses WS-Fed.
I'm building a small web application using ASP.NET MVC3, in which I'm using the default ASP.NET Membership API to create and authenticate users.
There's also a small desktop client which updates the web application. My question is what would be the best way to authenticate the desktop client. Considering that users would register using their username and password via the website, I don't really want to store any user credentials on the desktop.
I was thinking about implementing an OAuth provider in my web application, and associating the token with the authenticated username. That way I would authenticate my desktop client like most twitter clients do now.
So basically my question, should I do OAuth, or maybe there's another popular option?
Why not expose a login action method that returns a token? This would avoid the added complexity of an oauth service. As long as your mvc app is decoupled and using services, your client can consume these same services.