I can't find my Flurry authorization key for push credentials. How can I obtain a new one?
I see that this is not something available from the interface: "Receive the token code to access the API. Save the token, there is no interface available to recall the token. (Keep this token secure. This token cannot be retrieved from Flurry systems.)"
You will need to create a new programmatic user, which will then generate a new token for you to use with the API.
Log into y.flurry.com
Select the Admin icon from the left navigation bar
Select Users
Click on +Programmatic User
Related
I'm using authentication code mechanism through Docusign's API for integration and works as expected.
Have a question regarding the documentation about implementation best practises, described in this page
Questions are related to the diagram at the end:
Question1
In Get the user's account ID, base URL and name (1st square) how do you recommend fetching the user/account information as before consent we don't know who is giving consent?
If it is related to users that may have given consent before, is it even necessary? If tokens already exist for the user, what is the purpose of verifying this scenario?
In the documentation it seems this is reinforced further with what is stated next:
How will we know what is the account/user information before the user gives consent?
Question2 (Similar to above)
In Collect the account ID (GUID) and name of the user, when no access token is found, I'm assuming we should redirect the user immediately so that the use gives consent again. Similar to the question above, in the diagram it indicates we should do this action "Collect account/user info" somehow before redirect for consent? We only know it afterwards as well, so is it needed?
It would be great if it would be possible to clarify the above!
As Inbar commented, that diagram needs some work. I'm sorry for the confusion.
Here's my recommendations for user present (Authorization Code and Implicit grant flows) and user absent (JWT grant flow).
All authorization flows
Determine if your users will typically use your application with a particular eSignature account or with any of their accounts. (It is common for customers to have access to more than one DocuSign eSignature account.)
If a particular account will be used, then provide an installation screen for your app where the admin can enter the account ID (use the guid format).
Your installation screen should also enable the installer to set
the DocuSign OAuth service provider, either production account.docusign.com or demo account-d.docusign.com
User present: Authorization Code and Implicit grant flows
Your app may or may not have its own login sequence for users. Your app needs a DocuSign access token for making API calls to DocuSign APIs.
When your user wants to authenticate with DocuSign:
Start the Authorization Code or Implicit grant flow.
When the flow is done, your app has an access token.
If the Authorization Code grant flow was used then you also have a refresh token.
Use the oauth/userinfo API call to obtain information about the user:
Their name and email
The eSignature accounts they have access too, and which of those accounts is the user's default account
For each account, the name of the account and the baseUrl for making API calls to the account.
If your app's users use a preferred account, then check that the user has access to the preferred account. Else, note the account id of the user's default account. (Also be prepared to handle the cases where there is either no userinfo response, no account or no default account for the user. These are infrequent DocuSign errors and can be fixed by contacting DocuSign Customer Support and referencing this article.
Use the expires_in OAuth response attribute to calculate your expires datetime. Then subtract 10 minutes so you have a buffer between the time you'll last use the access token and when it actually expires. You now have the last_use time.
Store the user's information, including the account id, base url for the account, access token, and last_use datetime.
If you have a refresh token, store it (and the user's information) in non-volatile storage.
When your application wants to make an API call
If you have a current access token for the user (last_use datetime is after the current datetime) then use it.
If the last_use time has passed, then use the refresh token if you have it. When refreshing the toke, you'll receive a new refresh token. Store it in non-volatile storage, overwriting the prior refresh token.
If no refresh token, then your app will need to ask the user to authenticate again.
Do not use oauth/userinfo again after either the token was refreshed or the user authenticated again. Keep and use the userinfo obtained after the person first logged in.
When your user wants to use a different account
Provide a "Switch accounts" feature to enable users to choose which of their accounts should be used. (Only applies if any account can be used with the application.)
User not-present: JWT grant
Your app's configuration screen will also need the user id in guid form. You can either store these values or look them up from DocuSign.
Decide whether a specific account is needed or not (see above).
Decide how the user will grant consent. See this video for more info.
First time your app needs an access token after a reboot
Use the JWT user grant to obtain an access token
As above, calculate the last_use datetime including a 10 minute buffer.
Use oauth/userinfo as above to determine if the user has access
the account or what the user's default account is. Also obtain the account's base_url.
Store the information.
Use the access token to make the API call.
Subsequent API calls
Check the last_use datetime. If it hasn't yet occurred then use the stored access token. If it has occured, then redo the JWT user grant flow but do not make another oauth/userinfo call--use the prior information.
Question 1 - You do not need to remember which user gave consent. That is not something you should do anyway, because users can revoke consent and then your information will be inaccurate. The system will ask for consent if needed (and if you ask for additional scopes it may be needed even if consent was given for example).
Question 2 - You should redirect immediately, whether consent is needed or not is unclear, but the user will either have to login, or just redirected if they have a cookie and consent is also based on their circumstances.
I'll consent (no pun intended) that we can improve this diagram and make it easier to understand. I would suggest implementing a simple scenario first and seeing how it work before moving on to the more advanced scenario (by simple I mean every time a user need to log in as if it was their first time).
What I ideally want to achieve is to be able to Login with Google SignIn, and put authentication on my Nodejs server's endpoints.
What I have done till now is log in the user in the browser, and send the IdToken to the server, validate this TokenId using verifyIdToken() using this link.
https://www.google.com/search?q=verify+idToke&rlz=1C5CHFA_enIN936IN936&oq=verify+idToke&aqs=chrome..69i57j0i13l2j0i13i30l3j69i60l2.12008j0j7&sourceid=chrome&ie=UTF-8
Question:
Once verified, should I generate an access_token using some package, and use that to secure my server's API? Or Use Google SignIn's IdToken as an access token for it?
Or Is there some other flow I'm not getting?
The id_token contains information about the user i.e. email, name, and profile picture.
If that's all that your application needs then the access_token won't be of use to you.
If you're trying to access/modify data belonging to the user, (i.e. trying to add an event to their calendar using the calendar api) then you need the access_token. The access_token is what will give you access to the user's account. If your application requests offline access to the user data then you will also receive something called a refresh_token that will let you regenerate your access token once it expires. If you add the refresh token to your oAuthClient it should automatically renew the access token for you when you make an api call.
Based on what you described I don't think you need the access_token and the id_token might be all you need.
More information is available on this page: https://developers.google.com/identity/protocols/oauth2
I was able to implement a NodeJS application to sign in with my quickbooks developer account using OAuth2.0.I have the client key and the secret key and I am able to get the access token by signing in to quickbooks with their pop up and it redirects me to my application, and then the user is able to send invoices or get data from this quickbooks account.
However, I want the user not to have to sign in to quickbooks in order for it to send invoices or any other operation on quickbooks. I want to be able to write the functionality the application is allow to perform on the QuickbooksAPI by automatically signing in into quickbooks. How can I achieve this?
To word this differently, I want the NodeJS server to log in into quickbooks automatically if application user has the roles or permission to do a quickbooks action, such as creating and invoice or retrieve information. The application should grant itself permission to the OAuth2.0. How do I do this? with a JWT token? Not sure
A bit of background: I was able to accomplish Oauth2.0 authentication by using node-quickbooks by mcohen module.
Thank you in advance
The application should grant itself permission to the OAuth2.0. How do I do this?
You can't.
But you may also be misunderstanding how OAuth is supposed to work.
You need to have the user go through the OAuth process ONCE. EXACTLY once. Never more than once.
Once you have them go through that process once, you get back an access token and a refresh token.
You can then use those tokens to get updated tokens whenever you want (e.g. refresh your access/refresh token programatically, without any user interaction at all). See the docs:
https://developer.intuit.com/app/developer/qbo/docs/develop/authentication-and-authorization/oauth-2.0#refresh-the-token
So, have the user go through OAuth once. Then store the tokens in your app. Refresh the tokens via the refresh token API. The user just has to auth exactly once, and then everything else you can do automatically forever going forward.
I have a question regarding security when working with refresh tokens. Lets say I have a web application which has access to a user's google calendar. Therefore I need to do the following steps:
Get a client ID and a client secret from Google.
The user of my web application gives permission to his calendar.
I get a refresh and an access token.
I send the access token to the Calendar API and get access to the user's calendar.
I can refresh the access token with the refresh token, which is saved in the database.
What would happen if someone gets access to my database or in general would have the refresh token of one of my users?
Can an attacker access the calendar with the refresh token or is the token linked to my client ID and client secret? Is it only possible to access the users calendar when my web application authenticates via the OAUTH2 API with my client ID and client secret?
Thank you
Yes, it is/should not be possible to use a refresh token with a different client than it was issued to.
Refresh tokens are typically opaque strings, but in the issuer they should be linked to the authenticated client. That is why you need to send your client is and secret along when you use the refresh token.
Assuming that the client is able to keep a client_id and client_secret from the attacker, the regular approach is to treat and store the refresh_token in the same way. So even though technically it is not possible to obtain a new access token without the client credentials, in practice the attacker would get a hold of the client credentials in the same way as he got hold of the refresh token.
I tried to create a new playlist for a user different user on Spotify using my developer account's credentials (used the authentication key which was generated by using developer's ID as the owner ID). But it didn't work and displayed the following error message.
error message: "You cannot create a playlist for another user."
I want to know the way of creating new playlist on one account using another account's credentials.
I want my users to be able to work with spotify playlists using my application.
Thank you.
As you've already quoted:
"You cannot create a playlist for another user."
The access token used when making a Create a Playlist request needs to be authorized by the user for whom you're creating the playlist. Otherwise, any application could create a playlists on users' behalf without their explicit permission.
This doesn't stop your application from creating playlists for other users though, but you'll need to use either the Authorization Code flow or the Implicit Grant flow to get the access token. (Access tokens retrieved through the Client Credentials flow isn't tied to any specific user.) These flows are part of the oAuth 2.0 standard and there are lots of documentation out there to read more about them. Please see Spotify's Authorization Guide for a guide that's specific to Spotify. Code examples for these flows are also available on Github.