I want to provide an access token to a mobile client to execute the following request:
https://my.tapkey.com/api/v1/Users/${id}/Mobiles
But then I get this error:
{"Message":"Authorization has been denied for this request."}
The error is consistent with lack of provision for scopes: But this scope is only available under Token Exchange and my current method is authorization code.
When I try adding the scope register:mobile I get this error:
Sorry, there was an error: invalid_scope
Request Id: 80020549-0000-d600-b63f-84710c7967bb
Using the scope register:mobile is only available for token-exchange clients.
https://developers.tapkey.io/api/scopes/#only-for-token-exchange-clients
Creating a third party app with unlocking experience is not available in combination of Tapkey users (authorization code flow). You have to use your own independent users with an Identity Provider and token exchange flow.
Because we don't know much about your use case, my colleague already contacted you and offered a consulting call. I encourage you to get in contact with him and explain your overall solution and discuss how to efficient integrate with Tapkey.
Related
There are a lot of various topics on that already but I want to be very explicit here:
I'm aware that Cognito API flows (also used by Amplify) return tokens with aws.cognito.signin.user.admin scope. And I'm also aware that I can't use those to call any of the OIDC endpoints (like /userinfo). But this is leaving me with quite a problem: how do you solve a case when user performs a global logout? Without calling endpoints like /userinfo, how can I verify that incoming access_token is indeed revoked?
Especially when one's using Amplify with it's client storing tokens approach, those can be easily stolen, and with an hour of expiry on access_token, someone can cause a lot of mayhem... I'm struggling with this very much, tried consulting AWS directly about this, but they don't seem to have any solution in mind, so maybe the community can help... I need my app to be as secure as possible. I'd prefer to use authorization_code flow with PKCE but doing it with custom UI is a journey on its own...
Thanks everyone in advance
Starting with an API defined in WSO2 with no scopes associated to its endpoints...
... I get an access token and invoke them correctly.
Now I modify and publish my API, assigning a scope to one on the endpoints so that it requires the editor scope:
Now I invoke that editor scoped endpoint with the previous access_token and it works. This shouldn't happen since the token was given with the default scope, not the editor one.
Now I restart WSO2 and try again with the same token, getting the expected result of access denied:
(900910) - The access token does not allow you to access the requested resource</ams:description></ams:fault>%
I have needed to restart the platform so that scope changes are considered!! Is this a bug, a expected behaviour (it shouldn't...) of is there any way to force the refreshment of the endpoint requirements (appart from just publishing the changed API).?
If you generate a new access token after either modifying or deleting
a scope of an API resource that you had previously invoked, you will
not be able to access that particular resource of the API for a period
of 15 minutes, which is the default Gateway cache period, because the
WSO2 API Manager Gateway is designed to cache the details of the
resource on its side.
Ref: https://docs.wso2.com/display/AM250/Scope+Management+with+OAuth+Scopes
This is not a practical problem in a typical production environment, as API updates in a production environment are very rare.
However, if this is really a problem for you, you can override the default scope validator[1] by extending it to not to use this cache. This is configured in identity.xml.
[1] https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/master/components/org.wso2.carbon.identity.oauth/src/main/java/org/wso2/carbon/identity/oauth2/validators/JDBCScopeValidator.java#L92
Inching closer...
I am building a contacts synchronization facility into our product (with PHP/javascript). We are using an incremental approach for access - initially requesting a base set of scopes, then we want to expand these scopes when (if) our client decides to use the extra facility.
Base set:
www.googleapis.com/auth/plus.login
www.googleapis.com/auth/plus.me
www.googleapis.com/auth/userinfo.email
Extended with:
www.google.com/m8/feeds
www.googleapis.com/auth/contacts
I can get the extra scopes using the gapi.auth.signIn() call, but that doesn't seem to give me a "permanent" access token to use - later requests to the API in PHP don't show the new scopes. Does that mean I have to have an explicit call to the gapi function any time I want the frontend to access contacts?
Also, how do I get an offline token that I can use for the background process that will do the synchronization? Do I have to have a separate token for offline access? Can I mix offline and online access using the same token, or do I have to have one of each?
thanks,
andy
The difference between both online and offline access is that when you request an access token, this token will expire after certain time, usually 60 mins. After it expires the user will have to provide again the credentials so you can receive a new token.
In this case it is an "online" token.
When requesting the access token and you provide the parameter access_type=offline you will receive a refresh token. After the access token expires, you can request a new request token using the refresh token so it is not necessary that the user provides again the credentials.
Here you can find more information about that: https://developers.google.com/accounts/docs/OAuth2WebServer#offline
hope it helps.
My app got white-listed for using the Ads API.
I was wondering in regarding to the authentication flow.
Say, that I need to retrieve and execute actions via the API on daily tasks ( with no user interaction) , I find the authentication process quite cumbersome.
Is there a way to work with my app access token instead of a user access token?
I want to be able to approve my app only once for each user and then to be able to work with no user interaction.
Can I achieve this?
App access token is not relevant for this case.
I had to work with the user access token.
I followed this doc: https://developers.facebook.com/docs/reference/ads-api/
Eventually , one should use some client side code in order to get a user permissions and then make another request for getting the user token.
So you'll have to call
https://www.facebook.com/dialog/oauth?client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&scope=ads_management,offline_access&response_type=code
Get the authentication code and make another call:
https://graph.facebook.com/oauth/access_token?client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&client_secret=YOUR_APP_SECRET&code=AUTHORIZATION_CODE
Then you'll get an access token which is valid only for two months, in opposed to what Facebook docs says in here:
https://developers.facebook.com/roadmap/offline-access-removal/
"Ads APIs are special cased to allow collection of statistics offline. PMD partners should use server-side OAuth flow in order to receive a non-expiring token rather than a token that has longer expiration time."
Too bad that the access token is not really valid forever...
According to "Exception 4" in this document , if you have Ads API access you should be able to get a non-expiring token if you use the correct workflow. Following the guidelines outlined here, if you use the server side OAuth flow, to make the following request you should get a non-expiring token:
GET /oauth/access_token?
grant_type=fb_exchange_token&
client_id={app-id}&
client_secret={app-secret}&
fb_exchange_token={short-lived-token}
thx for the feedback regarding the Access token process being cumbersome. Because this is a one to many solution - a single App ID can manage multiple ad accounts, on behalf of multiple people - we need to make calls on behalf of people.
You should be able to get a persistent access token for Ads API. If you are not getting it, please provide exact steps you are following so we can see if there is a bug or you might be missing a step.
Thx.
I'm having some troubles understanding how OAUTH-v2 works.
The OAuth version 2 spec reads:
Accessing Protected Resources
The client accesses protected
resources by presenting the access
token to the resource server. The
resource server MUST validate the
access token and ensure it has not
expired and that its scope covers
the requested resource. The methods
used by the resource server to
validate the access token (as well as
any error responses) are beyond the
scope of this specification, but
generally involve an interaction or
coordination between the resource
server and the authorization
server.
How does this interaction between resource server and authorization server work in practice?
How does the resource server
determine that an access token it
received is valid?
How does the
resource server extract the allowed
scope from the token to see if access should be granted to a particular resource? Is the Scope encoded in the access token, or does the resource server first have to contact the authorization server?
How is trust between the resource server and the authorization server established?
Access token attributes and the
methods used to access protected
resources are beyond the scope of this
specification and are defined by
companion specifications.
Can someone give examples for token attributes?
The reason this is out of scope for the specification is the wide range of ways to accomplish this connection between the two entities. The main question is how complex is your deployment.
For example, do you have one server managing authentication and access, and a set of discrete services each with its own servers serving the API calls? Or, do you have just one box with one web server which handles both authentication/authorization and the API calls?
In the case of a single box, not much is needed as the entity issuing tokens is the same as the one validating them. You can implement tokens to use a database table key and lookup the record in the database (or memory cache) on every request, or you can encode the scope, user id and other information directly into the token and encrypt it using a symmetric or asymmetric algorithm.
Things get a bit more complex when dealing with a distributed environment, but not by much. You still issue tokens at the authorization server, but the resource server needs a way to validate those. It can do it by making an internal API available to the resource server to ask the authorization server to "resolve" the token (which can be fast in a local environment), or the two can establish a public/private key pair or symmetric secret and use that to encrypt everything the resource server needs into the token.
Self contained tokens are longer but offer much better performance per-request. However, they come with a price - you can't really revoke them while they are still valid (not expired). For this reason, self contained tokens should be very short lived (whatever is acceptable to you to leave access open after it was revoked - e.g. many sites use one hour), with a refresh token good for a year or more to get new tokens.
One example of resource- to authorization server API is the one at Google Developers Website.
It doesn't specify the format of the access token though, but the response seems pretty universally useful.