I'm building a single-page application that will interact with an Authorization Server (in my case GitLab) and two Resource Servers (GitLab and my own REST api). My own REST api will also interact with GitLab on behalf of the user.
Now my question is whether to:
use the implicit grant, which will result in the user having an access_token that can then be forwarded to our REST api so that both the SPA and the REST server can make requests to the resource provider on behalf of the user
use the authorisation code grant where our REST api will exchange the code for an access_token and return it to the user
use both (authorisation code grant for the REST server, implicit for the SPA)
Related
We have several microservices that communicate with each other and all these microservices use Oauth2 authorization to allow access to its API. The flow starts from the UI where we use the standard 'authorization_code' flow and finally get an access_token to invoke a specific API-1 service (Registered for client_id '123'). The UI then sends a request to the API-1 (client_id 123) and our API-1 now verifies the access token passed with auth server. Once it is valid this API now wants to communicate with another API (API-2) (Our internal microservice) which needs an access_token. We cannot re-use the same access_token as it is intended for a specific client. API-1 could use a token exchange to talk to API-2 but the developers of API-1 do not wan to do any token exchange. What are the options we have in this case?
Thanks
The typical solution is to let API1 contact your token service, using its access token and exchange it using the token exchange standard, for a new access token to access API2.
See OAuth 2.0 Token Exchange and check with your token provider for details.
I have a Rest API that is used by different clients:
Browser, when using swagger
Postman, when calling API
Curl
Other HttpClients, jvm, Python and such.
I want all clients to get authenticated with Azure AD. So each of them has to have an email, authenticate itself in front of Azure AD and then pass some token to my Rest API, on the backend I will validate the token. I really don't understand which flow to use. The one that is closest to my scenario seems to be Credentials Flow but I still don't understand how it fits in.
This picture is what I am trying to achieve:
The OAuth 2.0 On-Behalf-Of flow (OBO) serves the use case where an application invokes a service/web API, which in turn needs to call another service/web API. The idea is to propagate the delegated user identity and permissions through the request chain. For the middle-tier service to make authenticated requests to the downstream service, it needs to secure an access token from the Microsoft identity platform, on behalf of the user.
Based on your scenario it is recommended to use On-Behalf-Of flow (OBO).
Our apis are being consumed by 3rd party deamon applications as well as client applications. For third party deamon application we can expose the api via the client credential oauth flow and for the client application(S) we use the implicit grant outh flow.
The challenge we are facing is that in case of the implicit grant flow the user details are fetched from the ACCESS TOKEN. But when the same api is used for the client credential flow the user details can not be fetched from the ACCESS token as it has only application specific details.
What is the the best api design approach to handle the above challenge ?
Do I need two set of api(s) one for integrating with client application and one for integrating with server application ?
Will the usage of any alternative oauth flow help ?
Refer to Authentication scenarios for Azure AD documentation, as you stated correctly user interaction is not possible with a daemon application, which requires the application to have its own identity. This type of application requests an access token by using its application identity and presenting its Application ID, credential (password or certificate), and application ID URI to Azure AD. After successful authentication, the daemon receives an access token from Azure AD, which is then used to call the web API.
The quintessential OAuth2 authorization code grant is the authorization grant that uses two separate endpoints. The authorization endpoint is used for the user interaction phase, which results in an authorization code. The token endpoint is then used by the client for exchanging the code for an access token, and often a refresh token as well. Web applications are required to present their own application credentials to the token endpoint, so that the authorization server can authenticate the client.
Hence, the recommended way is two have two version of api implemented with two different type of authentication based on your scenario.
Reference -
Daemon or server application to web API
Understanding the OAuth2 implicit grant flow in Azure Active Directory (AD)
Generally OAuth definition says that it is way where user gives an application access to his resources stored in other application (without exposing the actual username and password). But inside Owin, it is a way to implement token based authentication within an application. Although we can deploy the Authorisation application at different server. But crux remains the same. Could anybody shed some light. I am very confused.
Thanks in advance
If you take a look at the OAuth 2.0 spec you will find this:
The authorization process utilizes two authorization server
endpoints (HTTP resources):
o Authorization endpoint - used by the client to obtain
authorization from the resource owner via user-agent redirection.
o Token endpoint - used by the client to exchange an authorization
grant for an access token, typically with client authentication.
As well as one client endpoint:
o Redirection endpoint - used by the authorization server to
return
responses containing authorization credentials to the client via
the resource owner user-agent.
Not every authorization grant type utilizes both endpoints.
Extension grant types MAY define additional endpoints as needed.
So basically, you have 2 options:
1) Use the authorization endpoint where your end-user is redirected to a form that is handled by the authorization server
OR
2) Create your own form inside your app, get the end-user credentials and send that data to the authorization server, where it will be validated and return a token for you to use.
I'm considering an OAuth 2.0 scenario where the OAuth client is a web service:
user --> web service client (AJAX app on a browser) --> web service (OAuth client) --> web service (OAuth resource server)
However, I'm unable to map this scenario into any of the scenarios/use cases described in the OAuth 2.0 draft 22 or in the "OAuth use cases" draft.
Are there any references (e.g. docs, posts) regarding this kind of application?
Adding some names to clarify the discussion
user --> C (e.g. AJAX app) --> Service1 (OAuth client) --> Service2 (OAuth RS)
The AJAX client could use the implicit grant type to get an Access Token (AT) directly from the Authorization Server (As)'s authorization endpoint. This grant type is an optimization of the more well known authorization code grant type, i.e., three legged OAuth. (Browser based JavaScript clients can't keep secrets, so there I no sense making them exchange a code for an AT.) Then the Web service which, in this arrangement would be a Resource Server (RS), would exchange the AJAX client's AT for a new one using IINM the client credentials grant type by sending it to the AS's token endpoint. It would then send this second AT to the downstream service (also an RS). If the first AT is a bearer token, both services trust the AS, and the second service doesn't need info about the first service in the AT, exchanging tokens isn't needed.
HTH!