I am currently working on a project that includes the following:
One central identity server that authenticates users against Active Directory
Several different APIs that different users have different levels of access to
Several JS web apps that users log into in order to access the APIs
What authentication flow should be used in between the web apps and the identity server that allows the APIs to get information about the user and authorize the user within them? I'm a little stuck here.
You'd typically use the OAuth 2.0 Implicit Grant to obtain an access token for the JS web app that it can then use in calls to the APIs. The APIs can leverage the access token to find out about the Resource Owner who granted access to the API.
Update: see comment below about deprecation of Implicit over Code+PKCE.
Related
I have an old windows application written in VB.NET with SQL server backend. Currently the new user additions, deletion, adding entitlements etc. are managed by an old approval workflow system. After getting approvals, the user details and entitlements are inserted in to the SQL server database table manually.
I am trying to integrate this application with the SailPoint's Identity and access management. So the new user addition, deletion update and adding entitlements etc will be done through Sailpoint. For this, I would require to create a WEB API which can be called by Sailpoint and expose the functionalities(add user/delete user/add entitlements). The only consumer to this API is SailPoint.
I am new to OAuth and below are the grant types that I came across. But not sure which one I should be using in this particular scenario.
1.Implicit Grant
2.Resource Owner Password Credentials Grant
3.Client Credentials Grant
4.Authorization Code Grant
I have done research on the different authentication methods that we can use to secure the web api. But still confused on which one to apply in this scenario as this new web api is going to be made available in internet.
I already tried developing a POC with the OAuth 2.0 with password grant type referring this article. But when I read articles in the internet I found that the password grant type is not that secure and is deprecated.
Could you please advise on which grant type(client credentials/authorization code/implicit) to use in this scenario. I believe authorization code is used when the user is directly trying to access the API. In this scenario, SailPoint will be calling the API in the backend programmatically when they insert a new user in their UI.
I think it's a good approach to use client credentials in this case because the communication between IIQ and your Web API can be considered an API-to-API communication, I mean, IIQ is acting on behalf of itself in this communication.
See this article for more details - https://dzone.com/articles/four-most-used-rest-api-authentication-methods (bold part by myself)
OAuth 2.0 provides several popular flows suitable for different types
of API clients:
Authorization code — The most common flow, it is mostly used for
server-side and mobile web applications. This flow is similar to how
users sign up into a web application using their Facebook or Google
account.
Implicit — This flow requires the client to retrieve an
access token directly. It is useful in cases when the user’s
credentials cannot be stored in the client code because they can be
easily accessed by the third party. It is suitable for web, desktop,
and mobile applications that do not include any server component.
Resource owner password — Requires logging in with a username and
password. In that case, the credentials will be a part of the request.
This flow is suitable only for trusted clients (for example, official
applications released by the API provider).
Client Credentials —
Intended for the server-to-server authentication, this flow describes
an approach when the client application acts on its own behalf rather
than on behalf of any individual user. In most scenarios, this flow
provides the means to allow users to specify their credentials in the
client application, so it can access the resources under the client’s
control.
There is a food ordering system. There are around 12 or 13 APIs.
The end-user can search for restaurants, foods, filter things, etc. without logging in to the system. The login is only necessary for placing an order, see past orders etc. So, for like 10 APIs I don't need the user to login.
10 APIs (need to verify the third-party)
The rest (need to verify the third-party as well as the user)
The oAuth 2.0 solutions I have seen so far, they instantly asks for the users to login which is something I don't want.
It'd be really helpful for me if someone takes the time to explain a possible solution and how all those could fit together.
If no Authentication is required, then the information is "Public" and does not need protection from OAuth 2.0.
It would not be unusual for a APIs to be called by a WEB Application where the WEB Application needs to use OAuth 2.0 to access the APIs, but the end-user has no relation to the APIs. So the WEB Application needs an OAuth 2.0 client_id for access to the APIs. The client credentials grant is designed for this use-case: (RFC 6749 Section 1.3.4)
when the authorization scope is limited to the protected resources
under the control of the client ... when the client is acting on its
own behalf
The WEB Application may then at some point use OpenID Connect to Authenticate the end-user for access to some of the "protected resources".
I have developer an API that is secured by oAuth2 and Azure B2C. I now want to access that API from a legacy web forms application which is using Forms as it's authentication mechanism.
I have used hellojs successfully on the client side to trigger the authentication method in a separate browser window and then use the access token successfully to call my API but how do i do this from the server side?
All the examples I've seen when setting up oAuth2 involve securing an API using the OWIN middleware (e.g. with Facebook login, etc) but I need to retain the existing forms authentication and simply invoke code that calls the API and handles the access code/token etc.
If I need the backend system to make requests on behalf of a user, should I be storing the access token securely somewhere?
The simplest approach would be to have the users authenticate against B2C separately. Think of this in terms of "linking" their account in your Web Forms app to their B2C account. If you also request the offline_access from Azure B2C, you'll receive a Refresh Token that you can exchange for a valid Access Token when needed.
Ideally, you should pivot away from Forms authentication. It's a very outdated model. It may, however, be a non-trivial amount of work which is why many folks often choose to start with the "linking" strategy and only tackle Forms Auth when they're doing a larger refactoring of their app.
I'm trying to create a web api in Azure that allows a user to access it.
I don't care whether the user calls the api via postman, curl or a .net console app, as long as the user can authenticate against the AzureAD protecting the resource, he should be in.
However, all documentation I have seen so far require me to register a client with AzureAD.
So, I've got an example working, but I had to register the console app in AzureAD.
Now, there maybe hundreds or thousands of developers developing apps against my API. Obviously I don't want to have to register each single one with AzureAD. In fact, I don't even want to have to know about them.
How can I actually do that? I care about users, not client apps.
Or is this something AzureAD B2C does?
Now, there maybe hundreds or thousands of developers developing apps against my API. Obviously I don't want to have to register each single one with AzureAD. In fact, I don't even want to have to know about them.
You only need to register one app(web app) to protect the web API. And if you want the web api consumed by different organization, you need to enable the Multi-tenanted feature on the Azure portal.
After that, if the other developers want to consumer the web API, they also need to register the one app on their tenant and grant you web API app to their app. After that then can acquire the access token for the web API and request the web API with the access token.
More detail about the scenario about calling web API, you can refer the code sample below:
active-directory-dotnet-webapp-webapi-openidconnect
And if the sencario is multi-tenant, you also can refer the document below about detailed info:
How to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern
I'm looking for some guidance on what people think are the best set of technologies to use. We are looking to create a web portal to allow customers to register/login with standard credentials or their social accounts (Google, Twitter etc).
Once they are registered and logged in to the portal they can access our different web apps which will know who they are and what permissions they have based on a token. We will also need to secure a set of web APIs using some sort of OAuth mechanism, so the user would possibly create an account on the web app and then create an application which would give them the keys they need to access the API from their own app.
We have a basic portal app using MVC 4 and DotNetOpenAuth which allows a user to create an account and login with either a username and password or their Google, Facebook account etc.
The APIs would be MVC 4 Web APIs
Ideally the whole set up needs to be as simple as possible, I've briefly looked into using Windows Azure Access Control (ACS) as a way to cut out some of the heavy lifting but its hard to tell where exactly it all fits together.
Currently we run an ADFS 2.0 server and WIF to allow web login to our apps but it doesn't seem like it would be an ideal choice when integrating the social login and for securing the web APIs
I guess it could be two quite seperate parts, once they are logged into the portal, how would we go about providing some sort of claims token to the other apps they then access to understand who the user is and what they are allowed to do. And maybe the web API authentication/authorisation is its own entity?
Thanks for your time
We ended up using the built in MVC 4 login system and also added JWT token support, when a user is logged in a JWT token containing their claims is stored as a cookie. This is then automatically passed around our sites on the same domain by the browser, when the web API is called from javascript it checks for the token in the headers sent by the browser and either validates it and returns the correct data or returns an unauthorised response.
It doesn't cover all the bases, we can't give trusted third parties access to our web services yet