I have a custom ebay connector, and it currently operates using a Token, and is able to pull in orders from the client's seller account using the Trading API.
The programmer that wrote the majorit of the app has left, and I can't determine if the token is associated with the production keys in my developer app. I can't see a report or list of tokens attached or anything.
How can I determine if the token is operating under my developer account? The token appears to be the only credential used to link the system up.
Also, I don't actually know what the developer did to create the token in the first place. The app is not public, it doesn't appear on the client's Applications or Subscriptions, how does one control the auth tokens that they have in ebay when they are allowing access from private apps?
Thanks for any help. The client is hitting API limits and I need to get the program through compatible app chcking.
Mark
you can use this request to check the token validity
GetTokenStatusRequest
<?xml version="1.0" encoding="utf-8"?>
<GetTokenStatusRequest xmlns="urn:ebay:apis:eBLBaseComponents">
<RequesterCredentials>
<eBayAuthToken>$auth_token</eBayAuthToken>
</RequesterCredentials>
<ErrorLanguage>en_GB</ErrorLanguage>
<MessageID>$messageID</MessageID>
<Version>$api_version</Version>
<WarningLevel>High</WarningLevel>
</GetTokenStatusRequest>
Or you can do FetchToken request check API call list here
Related
I am developing a web-based application that will allow my trusted staff to edit the titles, descriptions, tags, etc. of my YouTube channel. In attempting to "Opt In" to my own application, I was sent to the callback URI with an error message:
You can't sign in to this app because it doesn't comply with Google's OAuth 2.0 policy for keeping apps secure. You can let the app developer know that this app doesn't comply with one or more Google validation rules.
Some history - when I first attempted to obtain a code to exchange to an authorization token, it actually worked! However, as I was writing the code to harvest the code and exchange it for the authorization token, I repeated the "Opt In" process multiple times. Before I was ever able to perfect my code to exchange the code for an authorization token, I began getting the error message to the effect that the app is insecure and cannot be signed in to.
More history - after reading a Stack Overflow article describing something similar, I deleted the project, created a new project, generated a new Client ID and Client Secret, and then repeated the test with the same failure.
I am the only Test User of the app. I can't find any notification in my console alerting me to nature of the security issue triggering the failures. I have reviewed the OAuth policies at
OAuth 2.0 Policies
and cannot find anything even remotely wrong.
What is wrong and how can I fix it?
I also had the same issue.
For me, it turned out that my redirect_uri is not valid. The redirect_uri that gives error:
http://localhost:8000api/vi/oauth/google
What are wrong in my case:
I should put a / before api.
vi is different from what I registered on GCP. It should be v1
I would suggest you to print out the redirect_uri when your app is performing code exchange, and verify every single characters carefully.
Additionally, check out the documentation of Redirect URI validation rules on Google to see if your redirect_uri comply with all the rules.
You probably changed the port where the project is running or you did not define the address where the project is running in Google Cloud.
Google Cloud → APIs and Services → Credentials → OAuth 2 Client ID → change Authorized JavaScript origin to the port that your app runs on the local or shared host.
The URL may take time to define, so it may not work right away, so you can also create a new credential.
For me the redirect_uri was correct, but as a result of an error, the access code was requested for a different client ID.
My use case is that once I have a user signed into my app, I use the Oauth token, resulting from the sign-in, when I make endpoint calls from my app to my custom server-- to authenticate the caller. E.g., I use Google Sign In in this way.
This method (e.g., with Google Sign In) has several useful properties:
Updated tokens are created automatically on the client app.
My custom server can easily verify the validity of the token, using Google's endpoints.
Initial token verification can take place early in the endpoint request processing-- without access to the custom servers database (as in the style in https://github.com/IBM-Swift/Kitura-Credentials).
My question is: Given that we're being told we have to incorporate Apple Sign-In into our iOS apps (if we offer general purpose sign-in facilities), how can I do endpoint authentication with my custom server?
I see two alternatives, neither of which I like very much.
First, I can have my client app send an Apple Sign In id_token to my server and ignore the exp (expiry) field. I can regenerate the id_token periodically (apparently, no more than once a day) and send it back to my client. I don't like this idea both because of ignoring the expiry of the token, and because of the need to periodically send the token from server to client. (My app uses multiple sign in systems and this just creates extra difficulty).
Second, I could have my client send an Apple Sign In refresh token to my server. My server would need, of course, to initially generate that refresh token and send it back to the client. I like this idea even less than the first idea. My initial token verification in my custom server would need to access its database to look for a match this token. I can't generally use an Apple endpoint -- because, again, Apple is apparently going to throttle this verification.
Additionally, I don't really like the idea that my custom server can, at best, check on token validity once a day. If the user revokes the app's credentials, I would hope my custom sever would stop being able to operate on behalf of the user relatively quickly.
Thoughts?
10/5/19-- update to the first alternative above. Upon actual use of https://developer.apple.com/documentation/signinwithapplerestapi/generate_and_validate_tokens for refresh token validation, I find that it is not actually generating an updated id token. It is generating an access token (but Apple doesn't define a use for that), and is validating the refresh token. And so, there is no way to send an updated id token to the client iOS app. Thus, using the first alternative, the expiry date of the id token cannot be used.
10/10/19-- update: I've written a blog article on this subject-- https://medium.com/#crspybits/apple-sign-in-custom-servers-and-an-expiry-conundrum-d1ad63223870
8/6/20-- update: Follow on blog article with possible path forward, pending details from Apple: https://medium.com/#crspybits/part-ii-apple-sign-in-custom-servers-and-an-expiry-conundrum-b3e9735dc079
In Get the most out of Sign in with Apple in WWDC 2020, at 11:30 in their presentation, they introduce server-to-server notifications to enable your server to monitor user account state changes on a real-time basis.
So far, few details on this though.
----------------- UPDATE (12/23/20) -----------------
I now have these server-to-server notifications working in a testing environment with my server. Some notes:
I decided on the endpoint to use, on my server, to allow Apple to send my server these REST endpoint requests.
I pasted that into developer.apple.com > Account > Certificates, Identifiers & Profiles > Identifiers > Select your app identifier > Click 'Edit' next to 'Sign In with Apple' > Server to Server Notification Endpoint
This endpoint is effectively unauthorized. E.g., it is made by Apple with no OAuth credential access to your server. How this is setup will depend on your server. I had a means to set up a new endpoint/route for my server that was unauthorized.
I have the client side and other parts of my server set up to allow creation of accounts using Apple Sign In. So, using one of those accounts, I now started taking actions that would cause Apple to invoke their server-to-server notification endpoint on my server. I wanted to reverse engineer the details of the endpoint request Apple is making, since details are scarce.
This provides some ideas on how to cause the notification events to occur:
How to revoke Sign in with Apple credentials for a specific app?
You can revoke credentials, but it's easier (because you can do it repeatedly) to enable and disable the email relay. Of course, to do this, you have to initially sign-in with Apple using the private/email relay.
I next learned two things:
a) After you take the action (e.g., revoke the email relay), the server-to-server notification endpoint is accessed on your server within about 30 seconds. I had added various log output into my server, so could watch my server log and see this happening.
b) The endpoint request Apple makes to your server has body data containing JSON in the following format:
{"payload" : "-- SNIP -- JWT"}
I'm using the following Swift structure to decode this.
struct ApplePayload: Decodable {
let payload: String // JWT
}
As Apple has indicated in the WWDC 2020 video (https://developer.apple.com/videos/play/wwdc2020/10173/), the main content of the body data is a JWT. Above, this is the value of the key "payload" in the JSON.
The next step is decoding this JWT. I just guessed that it would use the same mechanism for decoding as with the JWT in other parts of the Apple Sign In server-side process. And specifically, in decoding the identity token (a JWT) passed up to your server by a client using Apple sign in. See https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_rest_api/authenticating_users_with_sign_in_with_apple
I had some code that did this JWT decoding, so I factored that out and put it in a common place:
https://github.com/SyncServerII/AppleJWTDecoder.git
Integrating that into my server-side processing of Apple's server-to-server notification requests, I found that indeed this JWT can be decoded in this manner.
Another aspect that became evident is that the structure indicated by Apple in the WWDC 2020 video isn't 100% what is present in the JWT, after decoding. Specifically, in my tests so far at least the events field is not an array, rather it has a single value. See https://github.com/SyncServerII/AppleJWTDecoder/blob/main/Sources/AppleJWTDecoder/AppleSignInClaims.swift for a Swift structure.
I am now successfully parsing the JWT. The next main step on my server is to actually utilize the different event types in my server to take actions. For me this is going to involve the two account (not email) related actions:
User decided to stop using their Apple Id with your application. And
should be treated as a sign-out by the user. E.g., when a user decides
to disconnect your application from Settings. (From
https://developer.apple.com/videos/play/wwdc2020/10173/)
Also considered a request from user to "delete their app account"
(broader context: "Server to Server Notification Endpoint Sign in with
Apple server to server notifications allow you to receive important
updates about your users and their accounts. Notifications are sent
for each app group when users change mail forwarding preferences,
delete their app account, or permanently delete their Apple ID. Each
group of apps can have one URL, which must be absolute and include the
scheme, host, and path. TLS 1.2 or higher is required to receive
notifications. Learn more.") To see these docs, go to:
developer.apple.com > Account > Certificates, Identifiers & Profiles >
Identifiers > Select your app identifier > Click 'Edit' next to 'Sign
In with Apple' > Server to Server Notification Endpoint
case consentRevoked = "consent-revoked"
User has asked Apple to delete their Apple Id. The user identifier will now no longer be valid.
case accountDelete = "account-delete"
My plan is to take both of these events as equivalent- and delete the user's account on my server. I'm then going to have to consider how to communicate this to my client (iOS app). It will need to know that the user has deleted their account.
We have an OAuth/OIDC service developed in API Connect/Datapower.
When a user requests a new refresh_token - if any unexpected error occurs in the flow, the new refresh_token is not issued, and their existing refresh_token is revoked. This forces the user to go through a new consent flow. This can be problematic if large numbers of customers are affected due to some unexpected error. We would like the old refresh_token to still be valid in this scenario.
We raised this with our IBM support contact - and he said this works as intended (i.e. - it should revoke the old refresh_token as the first action - it is single use, regardless of outcome).
He did suggest that it is possible to configure the refresh_token to be used multiple times until it is revoked/expired.
I am not sure how to do this - or what versions it is supported in. He said '(in 2018.4.1.x)? For v5 gw, use extension to enable it, You will need the latest DP firmware release for the above'. It's been hard to get any clarity on this. The IBM developer forums even directed me to Stack Overflow...
Does anyone have any more information/experience with enabling a refresh_token to be used multiple times? Or what versions this is supported in (or links to any documentation about this)? I'm struggling to find anything concrete on this.
Thanks
I suppose he's talking about the count configuration. it is located just below Enable refresh tokens.
Section 'OAuth 2' -> Tokens -> Enable refresh tokens -> count
Hope this could be helpfull
For IBM API Connect version 2018.4.1, you can specify whether the refresh token for OAuth provider is One time use only or not.
See OAuth native provider>Tokens screen.
After an access token expires, if the option is enabled in the OAuth provider API, the application can use refresh tokens. Each refresh token is valid for approximately 31 days after it is issued and can be used only once to request a new access token. Along with the new access token, a new refresh token is also returned.
I've recently been experimenting with the Coinbase iOS SDK and I've been having issues retrieving a user's Ethereum, Litecoin and Bitcoin Cash balances and historic transactions. Currently, I've only managed to do this with Bitcoin, USD and EUR, which seems to be consistent with the behaviour of the demo app supplied by Coinbase.
I have configured an application on the Coinbase API Access page using OAuth2 and the generated client ID and secret are being used within the app.
The issue seems to stem from the fact that I modified the Coinbase iOS SDK to allow me to pass the account parameter as
‘all’. This, I had hoped, would allow me to view details of all user accounts (ETH, BTC, LTC etc.) however, I only get BTC, USD and EUR when calling ‘getAccountsList’ on the Coinbase object.
NSString *accessToken = [response objectForKey:#"access_token"];
Coinbase *client = [Coinbase coinbaseWithOAuthAccessToken:accessToken];
[client getAccountsList:^(NSArray *accounts, CoinbasePagingHelper *paging, NSError *error) {
for (CoinbaseAccount *account in accounts) {
// Only BTC, USD and EUR are in the accounts array at this point.
}
}];
This is surprising as the permissions request page correctly asks the user for all wallets, as you can see in the screenshot below:
I suspect a solution to this would be to use API keys, as you are able to specify exactly which accounts to grant access to. I plan to distribute the app however, so this technique should not be used.
Here is an example of the URL I am sending:
https://www.coinbase.com/oauth/authorize?response_type=code&client_id=CLIENT_ID_GOES_HERE&account=all&scope=balance%20transactions%20user&redirect_uri=com.example-name.example-app.coinbase-oauth%3A%2F%2Fcoinbase-oauth
Does anyone know how I can request access to all of a users accounts using OAuth and be able to retrieve details for each? Is the scope I defined incorrect in some way? The only alternative I can think of would be to request access one by one to each wallet and store individual access tokens. This wouldn't be a great user experience however.
Thanks!
Add the parameter
account=all
to the oAuth endpoint: https://coinbase.com/oauth/authorize?account=all&response_type=code...
Here are the details: https://developers.coinbase.com/docs/wallet/coinbase-connect/permissions
Coinbase Connect applications can request different access to user’s wallets. This access is defined by account parameter on OAuth2 authorization URL. Available options are:`
select - (default) Allow user to pick the wallet associated with the application
new - Application will create a new wallet (named after the application)
all - Application will get access to all of user’s wallets
I believe the iOS SDK is in need of an update. It still connects to old API version.
I'm using the original Coinbase SDK. No fork. in stead, next to the wallet:accounts:read scope, I also add ["accounts": "all"] as meta argument to the startAuthentication method.
AND. I am NOT using the getAccountList method, but instead the more general .doGet method with the api v2 accounts endpoint (so coinbase.doGet("https://api.coinbase.com/v2/accounts", parameters: nil) {(response, error) -> Void in
This gives me account info for all wallets. You do need to do some json processing on the response object in this case though.
First if you don't have one, you need to create an account on Coinbase
Then, please take a look first on the Coinbase digital api documentation, and I agree with you that it maybe easier to use the API to get data (if the target account is only your own personal account)
Because according to Coinbase:
API Key authentication should only be used to access your own account or merchant orders. If your application requires access to other Coinbase users’ accounts, do not use API Key. To securely access other Coinbase users’ accounts, use Coinbase Connect (OAuth2)
You have two possibilities:
USE API
Assuming user has grant wallet:accounts:read to the API key ( which allow you to List user’s accounts and their balances) according to the wallet permission documentation.
Once done, you may use the official wallet client libraries for iOS - coinbase is available through CocoaPods - by adding the following line to your Podfile: :
pod "coinbase-official"
USE OAuth2 PROTOCOL
According to this,
It is a slightly more complex integration than the API Key authentication method, but is more flexible. OAuth2 works well for web applications, as well as desktop and mobile apps.
You will find a lot of informations in the coinbase-connect integrating documentation, and you may also take a look on the official OAuth2 protocol website first.
Assuming you are OK with OAuth2, you will also have to ask user to grant you permission before requesting data.
As you need access to user wallet, you still have to request access token and add a scope parameter in the authorization request (Comma separated list of permissions (scopes) your application requests access to), if you need to see the full scopes list please refer yourself to this page.
The required scope is the same as API method: wallet:accounts:read, and your request will look like this:
GET https://www.coinbase.com/oauth/authorize?response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=YOUR_REDIRECT_URL&state=SECURE_RANDOM&scope=wallet:accounts:read
After a successful request, a valid access token will be returned in the response (like this):
{
"access_token": "6915ab99857fec1e6f2f6c078583756d0c09d7207750baea28dfbc3d4b0f2cb80",
"token_type": "bearer",
"expires_in": 7200,
"refresh_token": "73a3431906de603504c1e8437709b0f47d07bed11981fe61b522278a81a9232b7",
"scope": "wallet:user:read wallet:accounts:read"
}
Once you get the access token, you can make any API call corresponding to the previous scope if you add the following header to the request:
Authorization: Bearer 6915ab99857fec1e6f2f6c078583756d0c09d7207750baea28dfbc3d4b0f2cb80
Finally, you may refer to the API reference documentation to see all possible API call and the relative scopes.
To conclude, you need to grant permission, then list the user accounts, then you may get any account resource:
Account resource represents all of a user’s accounts, including bitcoin, bitcoin cash, litecoin and ethereum wallets, fiat currency accounts, and vaults.
Regards
Still no luck.
Tried with adding param account=all. It gave me access to all wallets (exactly same as op). However, in code, I can only get BTC Wallet, BTC Vault, EUR Wallet and newly created BTC Wallet. The new wallet was created by adding param account=new.
Tried with adding param account_currency=BTC,ETH and chose ETH Wallet on oAuth authorization. Did getAccountsList which returned 0 objects and no errors from the server.
Tried with revoking all API application access in my Coinbase account (Settings->Security).
Scope: balance transactions user
Endpoint: .../oauth/authorize?account=all&response_type=code&client_id=%...
I am using code in following link to Renew access token for Intuit QuickBooks integration.
https://gist.github.com/IntuitDeveloperRelations/7259345
but, I am unable to test this code as intuit renew its access token only after 150 days from token creation date and I've created token only few days back. So I don't know the output. Right now, it is generating xml response with error message.
Now this method is returning me a single string which seems to be the Access Token. Do I also need to renew Access Token Secret ? If yes, then how to generate it ? Or the output contains secret as well ?
Actually, Can you give me the output for this method?
A successful response looks like this:
<ReconnectResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://platform.intuit.com/api/v1">
<ErrorMessage/>
<ErrorCode>0</ErrorCode>
<ServerTime>2012-01-04T19:21:21.0782072Z</ServerTime>
<OAuthToken>qye2eIdQ5H5yMyrlJflUWh712xfFXjyNnW1MfbC0rz04TfCP</OAuthToken>
<OAuthTokenSecret>cyDeUNQTkFzoR0KkDn7viN6uLQxWTobeEUKW7I79</OAuthTokenSecret>
</ReconnectResponse>
Refer to Intuit's documentation.
Notice that you will get back both a new token and a new token secret which you should store.
Remember that you can use Intuit's OAuth Playground to generate shorter lived tokens to test with.
You can test Reconnect API in the following way-
1. Navigate to IPP Playground- Go to Manage My Apps->Click on your app
Fill in consumer key and consumer secret in links below.
Prod: https://appcenter.intuit.com/Playground/OAuth/IA/?ck=prodConsumerKey&cs=prodConsumerSecret
Alternatively, you can navigate to the Manage page for your app on stage or prod and click ‘Test connect to app (OAuth)’.
Enter the duration you would like for the issued OAuth tokens (e.g., 3600 for successful Reconnect) in the ‘Access Token Duration’ field.
Click on the Connect to QuickBooks button, go through OAuth flow to authorize a connection to a realm.
Under the resulting Post-Connection Interactions heading, click ‘Reconnect API Test’. Screen shot attached.
A new page will launch where your OAuth tokens are displayed. Copy these values to your application to test Reconnect.
See if this reconnection code sample helps:
http://developer.qbapi.com/Reconnect-to-Quickbooks-Online-.aspx