Related
I am missing some understanding of OAuth2 access_token hope someone can explain or guide me to what I am missing.
I am using Microsoft Azure AD as an authentication provider for my application, I used the returned id_token after successful authentication to extend it with some additional data custom to my application (to facilitate authorization).
I am doing this throw JWT.sign, I decode the data from id_token and add data then I sign it using a secret key saved at the server.
My question is, can I do the same for access_token? When I tried to do so, I get unauthorized.
Am I doing something wrong? Or this is not possible? And why is this happening, I don't find any request made to MS to validated my new signed access_token.
You should never change tokens issued - this is not a correct thing to do. But your point about using domain specific claims is totally valid - all real world systems need these for their authorization.
OPTION 1
Some specialist providers can reach out at time of token issuance and contact your APIs, to get domain specific data to include in tokens. See this Curity article for how that works. I don't think Azure AD supports this though.
PRIVACY
It is best to avoid revealing sensitive data in readable tokens returned to internet clients. If you include name, email etc in ID tokens or access tokens this may be flagged up in PEN tests, since it is Personally Identifiable Information and revealing it can conflict with regulations such as GDPR.
Curity recommends protecting access tokens by issuing them in an opaque reference token format - via the phantom token pattern.
OPTION 2
An option that would work fir Azure AD is to adopt the following approaches:
Look up extra domain specific claims in your API when an access token is first received, then cache results for further API requests with the same access token. See this Azure AD Code Sample class of mine for some code that builds a custom ClaimsPrincipal. Note that the API continues to validate the JWT on every request.
If the UI needs extra domain specific claims then serve them from your API, which can return both OAuth User Info and domain specific data from its ClaimsPrincipal to the UI. See this API controller class for how that looks. Personally I always do this and never read ID tokens in UIs - which should also never read access tokens.
Applications interacting with Azure AD, receive ID tokens after authenticating the users. The applications use access tokens and refresh tokens while interacting with APIs.
The id_token is a JSON Web Token (JWT) which has user profile
attributes in the form of claims. The ID Token is consumed by the
application and used to get user information like the user's name,
email.
The Access Token on the otherhand is a credential that can be
used by an application to access an API.
So if you need application to access api, there the access token is used and you may follow the suggestion steps provided by Tiny Wang
Similar to id tokens, access tokens are also signed, but they are not
encrypted. As per IETF OAuth (RFC 6749) standard specification ,
access token can have different formats and structures for each
services whereas, id token should be JWT format.
To validate an id_token or an access_token, your app has to validate
both the token's signature and the claims. To validate access tokens,
your app should also validate the issuer, the audience, and the
signing tokens.
So in production application, you should get id token by specifying
“id_token+code” or “id_token+token” as response_type to verify
whether the authentication is correctly succeeded. It means it uses
the id_token for authentication and “code” to exchange access_token
to access the resource for authorization.
In short id_token is used to identify the authenticated user, and the
access token is used to prove access rights to protected resources.
Refer this for the information regarding access token and id token.
So, I'm developing an API using slim/slim and league/oauth2-server to manage the OAuth2 connection. OAuth2 will be useful because I will need to use Client Credentials grant between services.
Then, I'm also developing an hybrid app with React Native. This app will requires user login by using e-mail and password or connecting with another services (such as Facebook, Google, Twitter, etc).
And I'm confused about what OAuth2 flow to use for this case. Across the web are a lot of articles saying that Resource Owner Password Credentials is not safe anymore, and we should use instead Authentication Code with PKCE.
But I can't discover or understand how to apply Authentication Code with PKCE in a first party app, because all documentation talks about you will need the uses a browser to get authentication code in redirect_uri.
The flow I imagine is something like that:
User open the app, then insert your credentials username and password;
This screen will connect to API /request_token URI sending { 'grant_type': 'password', 'username': username, 'password': password, 'client_id': CLIENT_ID }, considering it as a public app we can't send client_secret;
The API validates credentials and returns some data such as { "access_token": access_token, "token_type": "JWT", "expires_in": LIFE_SPAN }, here we will use JWT to gerenate the access_token based in public/private key;
Authentication done, the app will store the access_token while it's alive and when it expires will do the flow to refresh_token.
My question: is it safe? Scott Brady did some "aggressive" article talking it's NEVER safe.
How apps does this things? When I use Instagram app, for example, they own the app and the API, I don't need a browser in the User Experience flow. Are modern apps using "Resource Owner Password Credentials" or "Authentication Code with PKCE"? There is a away to avoid insert browser in the flow while using "Authentication Code with PKCE"?
[EDIT] Possible Solution
As Gary Archer said "Auth Code flow with PKCE is recommended - along with logging on via the system browser", but we are not talking about grant permissions to access users data or third-party apps.
As a designer I don't agree that loggin in the first-party app owned by the same API owner requires a browser this is the not the User Experience we are looking for. And all apps we see such as Instagram, Facebook, Uber... we just put your username and password and we have access to your account.
What I will do is create a custom version of Authentication Code with PKCE removing the required_uri.
[EDIT:2] The New Flow
After a lot of search, I found some answers I think was interesting to adapt. As above, I removed redirect_url from flow. Look:
The flow starts in a login screen, when user give your credentials;
Client generates a code_verifier then hashes code_verifier to code_challenge and sends it to Authorization Server with following parameters:
response_type=code : indicates that your server expects to receive an authorization code.
client_id=xxxx : the client id.
client_integrity=xxxx : app integrity check for first-party app.
code_challenge=xxxx : the code challenge generated as previously described.
code_challenge_method=S256 : either plain or S256, depending on whether the challenge is the plain verifier string or the SHA256 hash of the string. If this parameter is omitted, the server will assume plain.
username=xxxx : username to authenticate.
password=xxxx : hashed version of password.
state=xxxx : a random string generated by your application (CSRF protection).
Authorization Server will validates user authentication, stores code_challenge and return the authorization_code with a client_token;
After receive the aauthorization_code and client_token, Client saves the client_token and immediately send authorization_code back to Authorization Server with following parameters:
grant_type=authorization_code : ndicates the grant type of this token request.
code=xxxx : the client will send the authorization code it obtained.
client_id=xxxx : the client id.
code_verifier=xxxx : the code verifier for the PKCE request, that the client originally generated before the authorization request.
Authorization Server will validates all data and, if everything is right, will return the access_token;
Client will set Authorization header with the access_token and always send client_token to every request, it will be only accepted with both values are right;
If access_token expires, then Client will do a request to refresh access_token and get a new one.
Now, I will reproduce this logic to PHP language. If everything goes right and I hope it does, I will be back with definitive answer.
[EDIT] Clarifications
I'm using OAuth2 to user connect with your third-party accounts (Google, Facebook, etc). But user also can log to a local account in my database. For this case, user doesn't need to grant anything at all. So, no makes sense send user to a browser to him does your login.
I wondering if, to this case, local accounts, we can use Resource Owner Password Credentials or it's more safe Authentication Code with PKCE (we already conclude it's a better approuch). But Authentication Code with PKCE requires redirect_uri, do I need uses this redirection to log users into a local account where they don't need to grant access?
Let's go then. After a lot research, I found some approaches that I will apply and may work correctly. So, first of all, here is the challenges:
You must never trust in clients running in client side. There's a lot of concerns about, your applications can be decomplied, modified, the users devices can be with a malware or connection may suffer with a man in the middle attacking (MITM)...
An API Server, even using OAuth2, will be able to only identify WHO is accessing the resources, but not WHAT is accessing. Therefore, any sensitive information will be dangerous, anything can steal it and uses it.
Resource Owner Password Credentials makes part of OAuth2 protocol for authorize resource owner to access your resources. So, it doesn't make part of authentication process and you will your ruin if you treat it like that;
By using ROPC grant type there is no way to know if resource owner is really making that request, what make "easy" a phishing attack. Reminds about "you know WHO and not WHAT". For last, this kind of grant makes easy for whatever thing assumes the user identity;
This grant type also goes against OAuth2 propourse, since OAuth seeks to avoid the password use to access resources. That why many people say to don't use it;
For reinforce, it's important to highlight ROPC is not authenticating user, but it just authorizing him to access the resource server.
And yes, ROPC allows for refresh tokens, but there are two issues: first, client needs resupply credentials each time needed to get a new token; second, if using a long-term access code, then things get more dangerous.
To prevent a malicious thing from arbitrarily using user credentials there are access tokens. They replace passwords and needed to be refreshed in short amount of time. That's why they are so much better than HTTP Basic Authentication.
That's why is recommended to use in modern apps the Authentication Code with PKCE, it provides all features and benefits of using OAuth2 protocol. But, here cames a long discussion and, even, problem for developer community:
To get an Authentication Code some user needs to make your login in a browser, grant access, redirect back to client and, soon, client will receive a code to exchange for an access token.
This scenario works good and NEEDS to be used for third-party apps. But, what if it is a first-party app? When you own the database with user data and you own the "trusted" app, redirect user doesn't make any sense. Right?
At this moment, my question is: how can I use the AuthCode (PKCE) flow without redirect user? And, again, it's important to highlight that talking about OAuth2 protocol is always the same that "to grant client to access resource server" (authorization, not authentication).
So the real question is: why Authorization Code needs a redirection at all? Then, I came with the following answer:
This flow requires to know client credentials and user consensus to turn back an authorization code.
That's why I was wrong in my edits. There's no change needed in OAuth2 protocol (sorry me for think different). For this reason, what OAuth2 needs is a authorization mediator, above your layer. Thus, the authorization code not will turn back to client, but to authorization mediator that, finally, will return it to client. Makes sense?
How it gonna work? Well, will be need 4 different "cores":
Authentication Server: will be responsible to authenticate user credentials and client identity. The main objective is to prove "WHO is the user and WHAT is connecting to get authentication";
Authorization Mediator (one layer above OAuth2): will validate client unique identity to ensure client/user is "know" and can get an access token;
Authorization Server: makes part of OAuth2 implementation, nothing change. Will authorize a client to get your authorization code, access tokens an refresh tokens;
Resource Server: will allow access resources through an access token.
And, then, security techniques we may consider:
API Key: each application (client) will have your own API Key with permissions scopes associated with those keys. By using it, you can gather basic statistics about API usage. Most API services use statistics to enforce rate limits per application to provide different tiers of service or reject suspiciously high frequency calling patterns;
Mutual SSL Authentication: by using this technique client and server exchange and verify each other's public keys. Once the keys are verified, the client and server negotiate a shared secret, a message authentication code (MAC) and encryption algorithms;
HMAC: API Key will be separeted into an ID and a shared secret. Then, as before, the ID is passed with each HTTP request, but the shared secret is used to sign, validates and/or encrypt the information in transit. The client and server will exchange the shared secret with algorithm such as HMAC SHA-256;
Protecting code application: using code obfuscators will make harder to locate and extract sensitive data from app, such as secret shared, api keys, public keys...
Handle user credentials: providing a simple method to user login and prove your identity. After insert valid credentials, server can return a user token (JWT) and emulates a user session with this.
Let's look at flow:
Part one: autheticating user and client;
User will type your credentials and be asked to prove your identity using your e-mail or mobile number, after Client will send user credentials (such as { email, mobile_number, hash ( password ), verification_method }) to Authentication Server route /login;
Authentication Server will validate user credentials and send a one-time password to user confirm your identity (for e-mail or mobile number as choose by user);
Then, user will insert the OTP received and client will send back to Authentication Server route /login-otp including the verification method (such as { otp, verification_method });
At the end, Authentication Server will return a { hash ( shared_secret ) } to be used soon.
Part two: authorizing API access;
When receive shared_secret Client will stores securely at mobile app, then it will ask for a authorization code using PKCE calling /auth with { response_type, client_id, scope, state, code_challenge, code_challenge_method }, Authorization Server will validate credentials and return an authorization code with no redirects;
Later, Client will exchange received code to an access token accessing /token, but it will need to send some extra data: { payload: { grant_type, code, client_id, code_verifier }, timestamp, hash ( some_user_data + timestamp + shared_secret ) };
Authorization Mediator will receive this request and validate trying to generate the same hash generated by user. And redirect all data to Authorization Server that will validate client_id, code and code_verifier responding with an access token;
This new access_token will return to Authorization Mediator and, after, to client granting access to API resources.
Part three: accessing resource server;
Client will each time needs send a call to API /api containing the Authorization header and some extradata with { timestamp, hash ( some_user_data + timestamp + shared_secret ) };
Authorization Mediator will validates the shared_secret hashes, call Resource Server validating access_token and return data.
Part four: refreshing access token;
After access token expires, Client will send a call to /refresh-token containing the Authorization header and some extradata with { payload: { grant_type, refresh_token, client_id, scope }, timestamp, hash ( some_user_data + timestamp + shared_secret ) };
Authorization Mediator will validates the shared_secret hashes, call Authorization Server and return a new fresh token access.
A visual image for this flow:
I don't think it is a perfect strategy, but it replaces Resource Owner Password Credentials to Authentication Code with PKCE and gives some extra security techniques. It's way better then a single and simple authentication method, preserves the OAuth2 protocol and mantaein a lit bit more hard to compromise user data.
Some references and support:
How do popular apps authenticate user requests from their mobile app to their server?
Why does your mobile app need an API key?
Mobile API Security Techniques
Secure Yet Simple Authentication System for Mobile Applications: Shared Secret Based Hash Authentication
Auth Code flow with PKCE is recommended - along with logging on via the system browser. Also the AppAuth pattern is recommended.
https://curity.io/resources/develop/sso/sso-for-mobile-apps-with-openid-connect/
It is tricky and time consuming to implement though - so you need to think about it - sometimes using a cheaper option is good enough. Depends on the sensitivity of data being exposed.
If it helps here are some notes for an Android demo app of mine, which also focuses on usability - and links to a code sample you can run:
https://authguidance.com/2019/09/13/android-code-sample-overview/
First of all, do not invent a OAuth grant simply because you need to adopt it in your application. It will make tings complex to maintain.
In your scenario you need to provide social login (ex:- Login via Google, facebook). This of course a desired functionality one must support. But it doesn't limit you from obtaining end user credentials through a custom registration process. There are many reasons for this, for example not everyone use social media or a Google account. And sometims people prefer to register than sharing user identifier of some other service (yes, this is the opposite end of social login).
So go ahead, provide social login. Store user identifiers when first login through external identity server (ex:- Google). But also, have a good old registration step with password and an email.
For the past 10+ days I've read an watched ALL the content I could find on understanding OAuth2 and OpenID Connect, only to find that many people disagree on the implementation, which really confuses me.
To my understanding, all the articles and examples I found assume you want access to eg. google calendar, profile info or emails if you eg. login with google, but I do NOT need to access other than my own API's - I only want to use Google, Facebook etc for logging in, and getting an id which I can link to my user in my own database - nothing more than that.
I'll try illustrate my use case and use that as an example.
A note on the diagram: the Authentication service could probably be built into the API Gateway - not that i matters for this example, since this is not about "where to do it", but "how to do it the best way" possible, for an architecture such as mine, where it's used for my own API's / Microservices, and not accessing Google, Facebook etc. external API's
If you can understand what I'm trying to illustrate with this diagram above, please tell me if I've misunderstood this.
The most basic requirements for this architecture you see here are:
Users can login with Google, Facebook, etc.
The same login will be used for all micro-services
OpenId user will have a linked account in the database
User access is defined in my own db, based on groups, roles and permissions
I do not intend to use external API's after the user is authenticated and logged in. No need for ever accessing a users calendar, email etc. so I really just need the authentication part and nothing else (proof of successful login). All user access is defined in my own database.
So a few fundamental questions comes to mind.
First of all, is OpenID Connect even the right tool for the job for authentication only (I'll have no use for authorization, since I will not need read/write access to google / facebook API's other than getting the ID from authenticating)?
People generally do not agree on whether to use the ID or Access token for accessing your own API's. As far as I understand the ID token is for the client (user-agent) only, and the access token is for eg. accessing google calendar, emails etc.... External API's of the OpenID Provider... but since I'll only be accessing my own API's, do I event need the access token or the ID token - what is the correct way to protect your own API's?
If the ID token is really just for the client, so it can show eg. currently logged in user, without going to the DB, I have 0 use for it, since I'll probably query the user from from the db and store it in redux for my react frontend app.
Dilemma: To store user details, groups, roles and permission inside JWT or not for API authorization?
By only storing the user identifier in the token, it means that I always allow authenticated users that has a valid token, to call endpoints BEFORE authorization and first then determine access based on the db query result and the permissions in my own database.
By storing more data about the user inside the JWT, it means that in some cases, I'd be able to do the authorization / access (group, role, permission) check before hitting the API - only possible with user info, groups, roles and permission stored inside a JWT issued upon login. In some cases it would not be possible due to eg. the CMS content access permissions being on a per-node level. But still it would mean a little better performance.
As you can see on the diagram I'm sending all API requests through the gateway, which will (in itself or with an authentication service) translate the opaque access token into some JWT with an identifier, so I can identify the user in the graph database - and then verify if the user has the required groups, roles and permissions - not from an external API, but from my own database like you see on the diagram.
This seems like a lot of work on every request, even if the services can share the JWT in case multiple services should need to cross call each other.
The advantage of always looking up the user, and his permissions in the db, is naturally that the moment the user access levels change, he is denied/granted access immediately and it will always be in sync. If I store the user details, groups, roles and permission inside a JWT and persist that in the client localstorage, I guess it could pose a security issue right, and it would be pretty hard to update the user info, groups, roles and permissions inside that JWT?
One big advantage of storing user access levels and info inside the JWT is of course that in many cases I'd be able to block the user from calling certain API's, instead of having to determine access after a db lookup.
So the whole token translation thing means increased security at the cost of performance, but is is generally recommended and worth it? Or is it safe enough to store user info and groups, roles, permissions inside the JWT?
If yes, do I store all that information from my own DB in the ID Token, Access token or a 3rd token - what token is sent to the API and determines if the user should be granted access to a given resource based on his permissions in the db? Do I really need an access token if I don't need to interact with the ID providers API? Or do I store and append all my groups, roles, permissions inside the ID token (that doesn't seem clean to me) issued by OpenID connect, and call the API and authorize my own API endpoints using that, even if some say you should never use the ID token to access an API? Or do I create a new JWT to store all the info fetched from my database, which is to be used for deciding if the user can access a given resource / API endpoint?
Please do not just link to general specs or general info, since I've already read it all - I just failed to understand how to apply all that info to my actual use case (the diagram above). Try to please be as concrete as possible.
Made another attempt to try and simply the flow:
The following answer does only apply for a OpenID Connect authentication flow with a 3rd party IDP (like Google). It does not apply for an architecture where you host your own IDP.
(There are some API gateways (e.g Tyk or Kong) which support OpenID Connect out of the box.)
You can use JWTs (ID token) to secure your APIs. However, this has one disadvantage. JWTs cannot be revoked easily.
I would not recommend this. Instead you should implement an OAuth2 authorization server which issues access tokens for your API. (In this case, you have two OAuth2 flows. One for authentication and one for authorization. The ID and access token from the IDP are used only for authentication.)
The following picture shows a setup where the API gateway and authentication/authorization server are two separate services. (As mentioned above, the authentication/authorization can also be done by the API gateway.)
The authentication flow (Authorization Code Grant) calls are marked blue. The authorization flow (Implicit Grant) calls are marked green.
1: Your web app is loaded from the app server.
2a: The user clicks on your login button, your web app builds the authorization URL and opens it. (See: Authorization Request)
2b: Because the user hasn't authenticated and has no valid session with your authorization server, the URL he wanted to access is stored and your authorization server responds with a redirect to its login page.
3: The login page is loaded from your authorization server.
4a: The user clicks on "Login with ...".
4b: Your authorization server builds the IDP authorization URL and responds with a redirect to it. (See: Authentication Request)
5a: The IDP authorization URL is opend.
5b: Because the user hasn't authenticated and has no valid session with the IDP, the URL he wanted to access is stored and the IDP responds with a redirect to its login page.
6: The login page is loaded from the IDP.
7a: The user fills in his credentials and clicks on the login button.
7b: The IDP checks the credentials, creates a new session and responds with a redirect to the stored URL.
8a: The IDP authorization URL is opend again.
(The approval steps are ignored here for simplicity.)
8b: The IDP creates an authorization and responds with a redirect to the callback URL of your authorization server. (See: Authentication Response)
9a: The callback URL is opened.
9b: Your authorization server extracts the authorization code from the callback URL.
10a: Your authorization server calls the IDP's token endpoint, gets an ID and access token and validates the data in the ID token. (See: Token Request)
(10b: Your authorization server calls the IDP's user info endpoint if some needed claims aren't available in the ID token.)
11a/b: Your authorization server queries/creates the user in your service/DB, creates a new session and responds with a redirect to the stored URL.
12a: The authorization URL is opend again.
(The approval steps are ignored here for simplicity.)
12b/+13a/b: Your authorization server creates/gets the authorization (creates access token) and responds with a redirect to the callback URL of your web app. (See: Access Token Response)
14a: The callback URL is opened.
14b: Your web app extracts the access token from the callback URL.
15: Your web app makes an API call.
16/17/18: The API gateway checks the access token, exchanges the access token with an JWT (which contains user infos, ...) and forwards the call.
A setup where the authorization server calls the API gateway is also possible. In this case, after the authorization is done, the authorization server passes the access token and JWT to the API gateway. Here, however, everytime the user infos change the authorization server has to "inform" the API gateway.
This is a very long question. But I believe most can be summarised by answering below,
To my understanding, all the articles and examples I found assume you want access to eg. google calendar, profile info or emails if you eg. login with google,
You do not necessarily use Access token (ID token in some occasions) to access the services offered by token issuer.You can consume tokens by your own APIs. What these Identity Providers (synonym to Authorization server, or IDP in shorthand) is to hold identities of end users. For example, typical internet have a Facebook account. With OAuth and OpenID Connect, the same user get the ability to consume your API or any OAuth/OIDC accepted service. This reduce user profile creation for end users.
In corporate domain, OAuth and OIDC serves the same purpose. Having a single Azure AD account lets you to consume MS Word as well as Azure AD's OIDC will issue tokens which can be used to Authorise against an in-house API or an third party ERP product (used in organization) which support OIDC based authentication. Hope it's clear now
A note on the diagram is that the Authentication service could probably be built into the API Gateway - not sure if that would be better?
If you are planning to implement an API gateway, think twice. If things are small scale and if you think you can maintain it, then go ahead. But consider about API managers which could provide most of your required functionalities. I welcome you to read this article about WSO2 API manger and understand its capabilities (No I'm not working for them).
For example, that API manager has built in authentication handling mechanism for OAuth and OIDC. It can handle API authentication with simple set of configurations. With such solution you get rid of the requirement of implement everything.
What if you can't use an API manager and has to do it yourself
OpenID Connect is for authentication. Your application can validate the id token and authenticate end user. To access APIs through API Gateway, I think you should utilise Access token.
To validate the access token, you can use introspection endpoint of the identity provider. And to get user information, you can use user-info endpoint.
Once access token is validated, API gateway could create a session for a limited time (ideally to be less or equal to access token lifetime). Consequent requests should come with this session to accept by API gateway. Alternatively, you can still use validated access token. Since you validated it at the first call, you may cache for a certain time period thus avoiding round trips to validations.
To validate user details, permission and other grants, well you must wither bind user to a session or else associate user to access token from API gateway at token validation. I'm also not super clear about this as I have no idea on how your DB logic works.
First Appreciate your patience in writing a very valuable question in this forum
we too have same situation and problem
I want to go through ,as images are blocked in our company in detail
Was trying to draw paralles to similar one quoted in the book
Advance API In Practise - Prabath Siriwerdena [ page 269]Federating access to API's Chapter. Definitely worth reading of his works
API GW should invoke Token Exchange OAUTH2.0 Profile to IDP [ provided the IDP should support TOken Exchange profile for OAUTH 2.0
The Absence of API Gateway , will result in quite bespoke development
for Access Control for each API Check
you land up in having this check at each of the api or microservice [ either as library which does work for you as a reusable code]
definitely will become a choking point.]
Our team is starting to build out a SMART on FHIR (SoF) application. SoF uses OAuth2 access_tokens to represent authorizations. Our app is using the code grant to get a token (https://oauth2.thephpleague.com/authorization-server/auth-code-grant/).
I'm pretty new to OAuth2 (used to SAML) and have been reading up on the standard. I think we may be conflating what the access_token is intended to represent.
Is the intent in OAuth2 that the access_token represents the permissions the resource owner (end user) has granted to the client (web application) to perform on their behalf?
Or is the intent to rely that the resource owner (end user) is allowed to preform certain operations?
For example say the auth token request has a scope called 'contacts-update'. If we get an access_token back with this scope, does that mean the user has allowed the application to attempt to update contacts (on their behalf) or does it mean that the user has the underlying requirements (they are in the update contacts role) to be able to update contacts?
As you wrote, the OAuth2 access token represents a permission delegation from a resource owner to a client (application), so the client can perform operations on behalf of the resource owner. That's also why there is a consent page - the user agrees on giving the application permissions (scopes) it requested.
Sometimes, people want to use OAuth2 as a central authentication server and a permission configuration for their applications. They want each application to see all permissions the user has configured for it. Then it doesn't make sense for application to ask for specific scopes, but to configure the OAuth2 server to return all relevant for that application (identified by a client_id). But I don't think this is the intended way of usage and the OAuth2 specification doesn't cover this scenario.
OAuth2 can also be used for authentication only, if it supports OpenID Connect extension. Then applications can ask for ID tokens. ID token proves identity of a user and the permissions are handled in each application separately.
If I have an API secured with Azure Active Directory, what is the flow when an external API wants to talk to my internal API?
Is this just an API to API call as normal or is this a special circumstance and needs handling a different way?
Is this just an API to API call as normal or is this a special circumstance and needs handling a different way?
The special circumstance may depend on the confidentiality of the resources served by these api(s) and the level of security your application needs. In the end it is an api to api call only.
There are two approaches you can use if Azure Active Directory (AAD) is your Identity Provider for the entire application.
Application Identity with OAuth 2.0 client credentials grant provided by AAD. The calling API makes a request to AAD token endpoint with its client id, client secret (credential) and the application id (the unique id for the callee API) to receive an access token as response. This token is used as Bearer token to call the downstream API. In this approach client id, client secret, application id that are exchanged for an access token, are static values. Some one who has access to these values may find a way to compromise application security (highly unlikely).
The second approach is Delegated User Identity with OAuth 2.0. A request is made to AAD token endpoint with client id, client secret, the access token received as part of calling the tier1 API and a special on_behalf_of parameter to receive an access token, refresh token as response. We preferred this approach as it uses a dynamic value (access token from tier1 api) and also provides a refresh token.
You can read more about these approaches here
If you do not want to use AAD, you can use asp.net built in OwinAuthenticationMiddleware to generate and validate your own access tokens. As said earlier it all depends on your application requirements and implementation details, but in the end it is an API to API call.
Hopefully this is helpful, please let me know if you have any questions.
Thank you,
Soma.
oAuth is done for loggin user to a webservice (see also reference here).
Use OAuth to give your users access to their data while protecting their account credentials.
As another webservice wants to consume one of your service best way to do so is to have another authentication method in order to authorize
Other API, I assume you are talking of machines and not users (alias humans).
So best way is to provide another auth mechanism in order to authorize machines to connect to your API in a safe way.
A simple way to do a machine connection is using a private PKI with public/private key.
A good reference for PKI : http://docs.oracle.com/javase/6/docs/technotes/guides/security/certpath/CertPathProgGuide.html