So here is a case:
I have identity server, client application and resource(API). Identity server provides user info on the endpoint http://identityserver:8080/connect/userinfo. If you send a request with valid access token you will get additional information about user. If I need this information on the resource how would I get it. I have two ideas:
Get the user info with client. (Client send request on userinfo endpoint and obtain information and then send it with request calling API.)
Resource API create a request on userinfo endpoint itself with access token. Problem here is that if I want to get token value from token store it is not supported information (Java Spring), so basically I do not have access token on resurce server.
I understand that userinfo endpoint is basically resource so my question is how to proceed if I want to get resource from another resource with keeping all best practice around OAuth2 and OpenID connect.
The solution is to use a different grant type. The most suitable is the Client Credentials. An identity server is needed to register a new client id and secret which can be used to exchange access token for API.
The access token is (I assume) available to your API so you can simply pass it on to other APIs (e.g. the userinfo endpoint) assuming the token contains the correct scope.
I'd recommend creating your own abstraction that makes it possible to get the raw ambient token used in the current request so you can then use it to call other APIs.
Related
Client application fetches the idtoken for authentication. But for the resource server, it needs to again make a call to Auth server and fetch the access token. Hence, does it make sense to make two calls for every oauth2.0 flow. The access token is what will be sent to the resource server. Am I missing something here.
With OpenID Connect, the ID-token is returned to the client at the same time as the access-token. So there is no specific need to make two requests to get the two tokens.
If you ask for an refresh token as well, then that one will also be returned at the same time.
The API (Resource Server) only receives access tokens from the client and it can without asking the identity provider validate the token. The API does not receive any ID-token.
While starting to integrate auth0, I came across this article
So its clear that to secure apis, all we need is the access_token and that is sent with each http request in the request Authorization header(Bearer scheme).
But then auth0(and possibly other providers) also send an Id_token that contains information about the user. My confusion is that how do I use this id_token to pass user information to my api. ( I have a spa running front end that authenticates to auth0 and gets these 2 tokens).
I can ofc call the userInfo end point in my api to get user info. But then wouldn't this defeat the purpose of the Id tokens?
The ID Token is consumed by the application and the claims included,
are typically used for UI display. It was added to the OIDC
specification as an optimization so the application can know the
identity of the user, without having to make an additional network
requests.
So my question is how do I access user profile in my api using id tokens?
"My confusion is that how do I use this id_token to pass user information to my api"
for that confusion, you just pass your JWT token. while generating JWT token, you need to add user information in payload part in JWT token. When your api get the JWT token, just check your JWT token is correct or not by the use of secret key and if correct, you can get data. How to get is just go from that JWT Authentication for Asp.Net Web Api
ID token is sent from the authorization server as a part of OIDC protocol. The purpose of this is to authenticate the user to your client application (SPA in this case). i.e. to let your API or the application know which particular user authorized the client to access a certain resource on its behalf.
Best way to use the ID token is by decoding and verifying it using a library. This will allow you to verify the signature of the token and any other claim that is included in the token (you can add custom claims to the tokens). Validation of those claims can be used to determine identity of the user and match with the user profile in your API. You will have to check the documentation related to your IdP(auth0) to figure out how to add new claims that are used by the user profile in your API.
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
I have been looking into OAuth2 lately and I think I understand the authorization process.
However, what I don't seem to understand is, once authorization has taken place and an access_token and a refresh_token have been established to make calls, how is the decision made based on the access_token if the request can or cannot access a specific resource?
I.e. a token is send to the server to request a photo. How does the logic on the server determines, based on the given token, that access to that particular photo is allowed or denied?
The access_token is usually an opaque artifact. There's nothing intrinsic that associates it with a resource (e.g. a specific photo). When the authorization flow starts, you typically request a specific scope that defines the access you need. If the owner of the resource consents to this access, then the request succeeds. Users can revoke access too.
All this is app specific code. Each app defines what their scopes are and how they enforce the check.
You might want to explore Authorization Server as an example.
The access token is actually an encrypted object, this object defines the scopes and may re-establish the authorization.
Imagine the service provider giving you an HMAC encrypted token which makes no sense to you, but the endpoint knows how to decrypt it. On decryption, it would have info like :
{"scope":"Photos", "userID":"3refefe"}
So, basically the module handling over the token to you encrypts this JSON (or any other format) object and gives you the encrypted token. When you hit the API endpoint, it sends token to the decryption logic and fetches this JSON object and hence knows what all you are authorized to do.
This object can contain any type of info and in any format depending upon the service provider. I have described how an OAuth provider works here.
This should explain the basics of a minimalist OAuth framework.
I am following this tutorial about OAuth2.0 https://developers.google.com/youtube/v3/guides/authentication
It looks quite clear how OAuth2.0 works. But I have a bit confusion at the access token part.
After obtaining an access token for a user, your application can use
that token to submit authorized API requests on that user's behalf.
The API supports two ways to specify an access token: Specify the
access token as the value of the access_token query parameter:
www.googleapis.com/youtube/v3/videos?access_token=ACCESS_TOKEN
if someone acquired this access token during the url transferring they can access this protected resource right?
How the server know if the request is coming from the client initially requested the access token?
UPDATE:
after reading this post Are HTTPS headers encrypted? my confusion is cleared. I thought query string is not encrypted during transmission in the network.
Generally I think the consensus is that OAuth 2.0 is a server side technology and all access tokens and communication should be transmitted using SSL as the bearer tokens need to be kept as secure as possible.
Also, you need to know that there are 2 types of flows in OAuth 2.0
i) Implicit grant flow - This is the flow where the user logs in to the service provider and his browser gets the access token. Say you have X.com and Log in via Facebook. Once the user keys in his FB credentials, the access token is sent to his browser.
ii) Authorization Code flow - In this flow (consider the above situation again), facebook will pass an authorization code to the user's browser. If anyone, somehow, intercepts the authorization code there is nothing he can do. An authorization code can be exchanged for an access when passed with valid client credentials. So, when the user logs in, his browser gets an authorization code which is passed to your server at X.com. from there you would hit the code-token exchange endpoint provided by FB and get the access token returned to your server!
Authorization code flow adds another layer of security, where the access token is visible only to the client + server and not to the user agent. And as you figured out yourself, the token is passed via HTTPS.