When to use IdentityServer 3 for OAuth - asp.net

I am new to Identitysever3 but I have worked with OAuth and OpenId.
I need to create a MVC client that will interact with QBO (Quickbooks Online). QBO uses OAuth by it's own.To start with I followed the github sample project from QBO community to use QBO REST API. This MVC app has OAuth stuff in MVC controller.
Now I need to create actual MVC project that will interact with QBO. I am after best practices to authorize my project. Here my authorize server would be QBO. So is my app is the right candidate to use Identityserver3?
My understanding is that I need to add Identityserver 3 project in my solution and use authorize server URI, client Id and client secret provided by QBO.
I assume Identityserver 3 is a framework that is the best way to use OAuth and OpenID connect as a separate project so it can be reused in other solutions. AND it's not an Authorization server, am I correct?
waiting for help please.

I assume Identityserver 3 is a framework that is the best way to use OAuth and OpenID connect as a separate project so it can be reused in other solutions. AND it's not an Authorization server.
This statement is not correct. In fact IdentityServer3 implements OAuth2 and OpenIdConnect and is an authorization server. If you have QBO as authorization server, you don't need to use identityserver3.
what you need is a client for OAuth2 and OpenIdConnect. You can use IdentityModel which is implemented by the same team that implements IdentityServer3.

Related

Combining cookie and token authentication in ASP.NET Core

I've REST services (Web API) and admin panel (MVC) in one project on ASP.NET Core 2.1. I want to secure my API with JWT token, and my MVC pages with cookies. Can I combinate these two authentication ways. How to configure my Startup.cs, Authorize attribute and sign in functionality.
I suppose you should use an OAuth 2.0 framework. please check IdentityServer4 it enables many features in your applications.
IdentityServer is middleware that adds the spec compliant OpenID
Connect and OAuth 2.0 endpoints to an arbitrary ASP.NET Core
application.
Typically, you build (or re-use) an application that contains a login
and logout page (and maybe consent - depending on your needs), and the
IdentityServer middleware adds the necessary protocol heads to it, so
that client applications can talk to it using those standard
protocols.

What is the recomended method for adding Authorization/Authentication to an MVC application that uses Web API

In most cases, I have used AD to lock down applications through IIS. In this case, I need to create an MVC Application that will have some Web API controllers and authentication/and authorization (roles). I was looking to try to use a stack overflow suggestion that I have found to several other posts.
https://identityserver.github.io/Documentation/docs/overview/mvcGettingStarted.html
Most of the answers that I have seen in Stack Overflow reference the above link
ex). Implementing Authentication and role based authorization in ASP.NET MVC web API service and MVC client architecture
The question that I have for the community that has experience with adding Authentication/Authorization to a combined Web Api/MVC project is if the identity server approach listed above is the best solution for this scenario and if there are other resources that I should look at also?
From your requirements (authenticate to use an MVC site and then be authorized to use a Web API) you'll need an OpenID Connect Provider such as Identity Server 3 (aka a Security Token Service (STS), an Authorization Server, etc). Basically something trusted by both the MVC site and the Web API.
The basic flow of things here is that your users will authenticate using OpenID Connect on your MVC site, after which they can get an access token to authorize access to the Web API using OAuth.
The mentioned tutorial is the best way to start. Near the end it takes you through how to access the API on behalf of the user.
ASP.NET Identity is a user/identity store. It is not add authentication or authorization to your application.

How to implement Claims Based Authentication using Web API?

I am going to be using Web API for an upcoming project and was asked to integrate an existing STS provider into the equation as my authentication mechanism. Therefore my Web API would be the RP (relying party). I don't need any support to provide the actual token (like creation of STS Provider), just need to incorporate claims based authentication to the configured STS provider and use it in my Web API REST based service.
Does anyone know if this is possible, and some examples on how to implement this? I see full examples with creating a STS provider, but like I said it already exists. I just need to trust it and use for authentication purposes.
Depends which protocols your existing STS supports. You need to find that out.
Basically you need to do this:
request a token from your STS (from within your client app)
send the token to the Web API
validate the token inside Web API
The thing you need to find out is if 1. works with your custom STS - then we can talk about 2 and 3 ;)

using WIF in ASP.NET Web API Service

I am trying to do something like this:
I have a MVC4 Web App and a Web-API service (hosted on two separate roles in azure)
Another role runs CustomSTS1.
The MVC Web App trusts the CustomSTS1
Now the customer logs into the site he is redirected to the STS login page.
Once logged in, he is redirected back to the MVC Web Site.
From this web site, the customer performs actions, which in turn invoke the web-API Service.
I have the SAML token in the web app, which I pass to the WebAPI service.
Now when I try to validate the SAML token at the Web API side, I get a
Message=ID1032: At least one 'audienceUri' must be specified in the SamlSecurityTokenRequirement when the AudienceUriMode is set to 'Always' or 'BearerKeyOnly'. Either add the valid URI values to the AudienceUris property of SamlSecurityTokenRequirement, or turn off checking by specifying an AudienceUriMode of 'Never' on the SamlSecurityTokenRequirement.
This is without the Web API service trusting the CustomSTS1
Once I setup the trust,
I am always given a HTTP 401: UNAUTHORIZED, whenever I try to make a HTTP Get request to the WEB API Service.
Now, My Question is, (I know that my current approach is definitely wrong)
How do I setup the Trust relationship with the CustomSTS1, such that the WebAPI service is able to do an ActAS on behalf of the user logged into the MVC site?
OR
Is this architecture wrong?
And is there another way to achieve this?
That approach is wrong conceptually. The MVC application should negotiate a new token for the Web API in the STS using ActAs. That's how it traditionally works for SOAP Services. However, Web APIs are moving away from SAML as it is a complex format that relies on different WS-* specs. OAuth 2.0 is becoming the standard in that area if you want to support SSO at that level.
Another approach is to establish an implicit trust between the MVC app and the Web API, so all the calls to the Web API from the MVC app are done through a more standard Http auth mechanism like Basic Auth using an specific set of credentials that only the MVC app knows. The info about the logged user in the MVC app is passed as additional information.
Regards,
Pablo.

Right Oauth 2.0 flow for mobile-app, web app

I am using Spring MVC project in the server to provide APIs to access data from both mobile-app and web-app.
Done research on security with Oauth 2.0 and thought Authorization code flow is suitable for both app's mentioned above, but little confusion on that. Can anyone tell which flow is best suitable for this type of scenario?
info:I need to implement Oauth 2.0 in server-side(Spring MVC project deployed in AWS).
If you are implementing your own authorization server and you already handle your consumerDB, I don't think you need an authorization code grant type of oAuth2. You can use Client Credential or ROPC. Authorization code is used when the log in is handled by a 3rd party (auth server).
There are 4 grant types in oAuth2 which is meant for different scenarios.. Refer : Securing an existing API with our own solution

Resources