I'm using the Xero OAuth2 code flow to authenticate my users. I'm trying to use the access token (a JWT) returned by Xero in order to authenticate requests against a Fauna database. This is theoretically possible by using a Fauna AccessProvider, which is a feature that allows third-party identity providers to authenticate requests against a Fauna database.
Fauna's docs on using its AccessProvider give examples for setting it up with Auth0, but I'm trying to determine whether I can use Xero's OAuth2 functionality instead. This would mean I need Xero to include a second value in the aud field of the access token JWT. From this other StackOverflow post and from looking at the access token, I can see that the aud field is set to the string 'https://identity.xero.com/resources'. Is it possible to configure Xero to set this value to an array that includes a custom value? I need it to include the Audience value set on my AccessProvider instance as documented in this blog post.
I looked through the settings for my app within my Xero developer account, and I don't see any place to add a value to the aud included in the access token.
I've read through the Xero documentation and Googled for any examples of this, but I didn't find any other writing on the subject.
I received this answer from Xero Support:
The access token retrieved from Xero using OAuth is not customisable and so you would not be able to add in the audience.
So it looks like this is not possible, unfortunately.
Related
You get the problem reading the title. Is there anyway I can sign up customers using commercejs. The documentation is only showing login/logout methods but not sign up.Is there anyway I can do it through commercjs. Or should I use other authentication service like Firebase Auth??
There is no specific way to register a user as Commercejs does not store any kind of password.
The only way for registering a user is to use https://commercejs.com/docs/api/#create-customer as per API reference docs. however if you want to integrate some kind of custom auth you should definitely use this reference:
https://commercejs.com/docs/api/#issue-jwt-for-customer
This allows you to issue a JSON web token for a customer directly using your secret Chec API key. This may be a desirable option if you are integrating your own customer authentication, and simply need a token to authorize API requests as your customer with.
I have personally used this method along with Firebase auth.
I'm trying to follow OpenID Connect best practices. For the simple scenario of calling API from application the OpenID Connect suggest to pass the Access Token (which is not included user identity), and if the API in some points need the user identity it should call /userinfo endpoint of OpenID Connect provider.
So the question is: Is it the best way to get the user identity in API?
Assume I have an end point named CreateOrderForCurrentUser() so each time any user call this api I need to call the /userinfo endpoint, it seems too much cost for calling an api.
Why I don't pass the Identity token to the API?
Or Why I don't put some identity claims in Access token?
Should I use HOK Token instead of Access token?
Any idea please.
It seems here is kind of same as my question: Clarification on id_token vs access_token
And he respond in comments: https://community.auth0.com/t/clarification-on-token-usage/8447#post_2
Which as my understanding means: put some identity claims in Access token (Custom Claims) and rely on that in the API.
But still it doesn't make sense. The OIDC insist to not use Access token as Identity and now we are going to add identity claims inside Access Token. Could any one clarify that?
ID_Token is used for your client app tells the app who you are , the audience of the ID Token is the id of your client app , with access token , API/resource knows whether authorized to access the API and perform specific actions specified by the scope that has been granted.
By default , it will include user identifier in access token(sub claim) , so you should know which user when calling CreateOrderForCurrentUser function . You could customize the access token to include more user related claims if needed . But i would suggest to simplify the access token , and you could use access token to acquire user information by invoking user's API endpoint .
I asked the same question in Auth0 Community and there is a discussion about it that might be helpful for others who have the same issue.
I copy the same answers here:
markd:
You are correct that you should not use an access token as proof of identity, but before you get to your API you should have already authenticated the user and received an id_token for them. If you have already authenticated the user via OIDC, as far as I know there’s nothing wrong with adding custom claims to the access token to pass data to your API. Your API could also use the client credentials grant type to pull data from Auth0.
Me:
I’m looking for the best practices. I want to be sure adding identity claims to the access token and rely on that in API does not broke any thing and is based on best practices or maybe the best practice is always call the /userinfo endpoint in API and don’t rely on Access token identity claims.
The API doesn’t know about the authentication process and don’t care about that. Any one any how pass the signed Access token to the API, it would be accepted. Now in API point of view is that proper way to rely on identity claims in Access Token? I have doubts. But I would be happy if we could ignore calling the /userinfo end point each time.
jmangelo:
I can share some (hopefully) informed views on this subject, but please do take them with a grain a salt and question stuff you disagree with or you don’t consider clear enough. When it comes with software the devil is on the details and in the security landscape it’s even more true so you need to consider best practices as what will likely be recommended for the majority of the scenarios and also what will likely be less risky; it does not mean that nothing else is possible.
For example, although the recommendation is indeed to use access tokens in requests to API’s this does not mean that there isn’t a specific scenario where technically it would also be okay to send an ID token instead.
Focusing on your particular questions and starting with the last one (3); we should not compare HOK and access tokens because they are not at the same level. In other words, you could question if in your scenario you should use bearer tokens or HOK tokens as this way and using the terminology of your linked page you would be choosing between two token profiles where each give you different characteristics.
At this time, the access tokens issued by the Auth0 service as part of API authorization are bearer access tokens so this question has only one answer if using the Auth0 service.
Jumping to the first question; it’s not that you cannot pass the ID token to the API, it’s just that the scenarios where that would be adequate are much more constrained. For example, an ID token is issued with the client identifier as the audience; it’s common to have multiple client applications so you have just coupled your API to how many client applications you have, because assuming you will validate the audience of the ID token, your API would now need to know the identifiers of every client.
For question (2) which I assume is also interested in why call /userinfo if you can include claims in the access token. I believe this can depend a lot on requirements and/or personal preferences. At this time the only format supported when issuing an access token to a custom API is the JWT format.
The above means that you have a self-contained token that once issued the API can mostly validate independently which is great in terms of scalability because the API does not need to make (frequent) external calls for validation purposes.
However, being self-contained this immediately means that any data you include directly in the token will be considered the truth for the lifetime of the token itself. If instead the API is calling /userinfo or even the Management API directly then you ensure fresh data at the cost of network overhead.
In conclusion, in my personal view the choice between network calls and embedded claims is more tied to the characteristics of the data you are interested in that just from a best practices point of view.
As a final note, even without any addition of custom claims an access token issued by the service in association to a custom API already conveys user identity. In particular, given the access token is a JWT, the sub claim will contain an identifier that uniquely identifies the end-user that authorized the current application to call the API on their behalf.
I can't access this particular Twitter API endpoint:
https://api.twitter.com/1.1/collections/show.json?id=576828964162965504
(with any ID I tried). The request returns an error with the message "Your credentials do not allow access to this resource" and code "220".
The App-only authentication Bearer Token I'm using for the request is exactly the same as for my requests to /search/tweets.json, /statuses/user_timeline/show.json, /statuses/show.json and /users/show.json, all of which work just fine. Also the collection is public, so App-only authentication should suffice, I'm thinking.
I'm somehow sure that I'm missing something here, but can't find it anywhere in the official API docs, nor on StackOverflow, nor on Google.
According to the Twitter API documentation, collections/show requires a user context - so app-only authentication will not work in this case.
Additionally, collection IDs are usually in the form "custom-756140390927872000" or similar. You can get the list of collection IDs from a user by hitting the collections/list?screen_name=handle query.
I am attempting to implement the eBay API and I have taken the steps to create an account, get access token. I submitted the call to obtain an oauth2 access token.
When studying the finding API documentation, it does not mention anything about OAuth2, only that when making calls you should pass your application ID. Does this mean that I do not need to pass an access token or retrieve one when performing calls to the finding API?
As far as I know you need :
api_endpoint
dev_id
app_id
cert_id
runame
auth_token
api_version
I am using these credentials detail and it works for me.
I assume workflow for OAuth is very similar in various sites. (twitter, linkedin)
I can successfully get requestToken, accessToken.
Is it okay, if I just store Accesstoken and use it later???
Yes, this is the generally accepted practice. I use this workflow on a few sites and based on the posts on the LinkedIn Developer's site, it looks like the method that most people are using.
The only trick is to cover yourself in the case that the user rejects your application's access rights; filter all responses from the LinkedIn API looking for an error indicating that the access token is no longer valid (you should be doing this filtering anyways for throttling issues).