I'm sure that I'm missing something, but I'm a little stuck. As part of a sign-up process we are building, we need to send a signature request to the person that signs up. For that, we want to use the eSignatures API.
I'm getting stuck on the Authentication process. Not the authentication itself, that works fine, but I'm not sure how this is going to keep working. As I understand, the tokens are going te expire eventually and I will need to get a new authorization code to request new ones. However, getting that code requires an in-browser permission by the DocuSign user. In my mind, that means this API integration is going to break every now and then and a manual permission is needed?
If you use Auth Code Grant, then yes, you will have to use refresh tokens and then even these eventually expire.
If you use JWT, you only need to get consent once per-user (or use administrative consent for entire account) and then you won't need to have user log again or do anything again to obtain new access token ever.
Related
My app is using JWT with individual consent. When, as a customer, I go to the Connected Apps screen at https://account-d.docusign.com/me/appconsent and revoke access to my app, the app still keeps working fine. No Docusign API calls fail, I can still create envelopes. Why? Is there another way to revoke?
The documentation page at https://developers.docusign.com/platform/auth/consent/ says "In cases where user consent was provided by an organization administrator (such as the JWT Grant), this consent can be revoked with the DocuSign Admin tool." But there is no link with more if about this "Admin tool" and I can't find it, and I don't think this applies in my case since I'm using individual consent.
I believe that the next time the app tries to use JWT to obtain an access token, it will fail.
But the already in use access token will continue to work until it expires at the end of its one hour lifetime.
If your experimentation doesn't support the above, please update your question.
I am making an app that returns a music playlist based on a user’s age. The user does not need need to log in to their account; they only need to provide their age. I also have no need for a database, so I decided that I want to make the application front-end only.
In order to make requests to Spotify’s API, I need an access token which I get via client credentials, because the user doesn't need to login using that flow. However, the script I used to get the access token must be run from the server-side, which I discovered here: Access-Control-Allow-Origin denied spotify api.
The alternative solution is to use the implicit grant flow, which will allow the script to be run client-side but will require a user to log in. So, both the client-credentials and implicit grant flow don't solve my problem.
How can my web app get an access token so that I don't need to implement a server-side or have the user log in?
Although the idea is different, I want to do something like this person is doing # http://sixdegreesofkanyewest.com/. No one logs in, yet he is able to get an access token and send api requests on their behalf. And I don't really see why that website would require a database either.
If I do end up having to develop a back-end, then I would be able to use client-credential flow. But, how would my back-end send the access token to my front-end without a DB?
Any help is appreciated. Thank you!
Implicit grant is recommended for javascript based application, who can not keep secrets safe. So you may have to strike out this option.
Having a server page, (hope the credentials kept safe in your server), then server app sending the request for token and rendering the page..
I guess that is what the http://sixdegreesofkanyewest.com/ will be doing.
So your option is server pages application. or an intermediate API call to get the access token for you and continue your application logics
One of the steps to authorize our application to access our DocuSign account requires a human to navigate to the oauth service (https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=...) then login to the account, and grant it access.
I've seen some references throughout the developer portal about this being something that will need done multiple times, and I've also seen it written on the same site that it only needs to be done once (the site is actually fraught with contradicting information).
Does anyone know if this step will need to be done more than once? It makes sense to me that it should NOT.
Much appreciated!
Chris
You are referring to https://docs.docusign.com/esign/guide/authentication/oa2_auth_code.html and it is a correct place for documentation for DocuSign. Now with above flow, you get two types of tokens i.e AccessToken and Refresh Token. If Access Token expires then you can use refresh token to get new set of access and refresh token and it does not need any consent from the user or a human action, it can be done using DocuSign OAUTH API from backend. But if the response to the refresh operation is an error, or if the new access token’s expires_in value is less than your threshold, you will need to repeat the initial authentication flow. So you need to do proper exception/error handling before taking user back to the consent/OAuth login page.
I'm completely new to OAuth, and have a workflow question. I'm using node/express/passport, and have successfully set up the app to redirect when requesting my /auth/google endpoint.
However, I consistently get routed to the Google permissions page where I have to offer my application access to my information. What is the mechanism by which I could log in/out without providing that access every time? Essentially, how do I let users log in without requesting permissions again, but still let them log in through Google?
The typical flow is to have your users log in on Google, like you're doing. Once they confirm your application's requested scopes, Google can provide your server with an authorization code which can be traded for an access / refresh token to be stored and used in the future.
Passport should abstract a lot of the back and forth away from you, though. Are you utilizing this library? And if so, are you storing the access and refresh tokens in your own local database for re-use (or at least the refresh token, so you can get a new valid access token when you need it)?
I'm creating a node.js application that will update playlists (owned by an account in which I have credentials) daily. According to the Spotify documentation, to add tracks to a playlist (https://developer.spotify.com/web-api/add-tracks-to-playlist/), authorization must be supplied using oauth2.
I'm struggling to find a way to do this completely server side with no redirects/etc. It seems like if I can get a refresh token, I can just use that?
I've been looking at the spotify web api node module (https://github.com/thelinmichael/spotify-web-api-node), oauth.io, and the spotify api.
Any ideas would be appreciated! There is only one account that will have to be authenticated, so it could be hard-coded at least for now.
You've picked the correct authorization flow - Authorization Code, since you need an access token that's connected to the user who owns the playlists you're updating. This of course also gives you the ability to refresh the token whenever you need to. (The expiration time is one hour, but you don't need to refresh the access token until your application actually needs to use it.)
As a sidenote, the Client Credentials flow is meant for server to server communication that doesn't require a user's permission, e.g. to search, read a playlist, or retrieve new releases. The Implicit Grant flow is meant to be used in frontends, and doesn't allow you to refresh the token.
I'm struggling to find a way to do this completely server side with no redirects/etc. It seems like if I can get a refresh token, I can just use that?
Once you have the refresh token you can continue to use it to retrieve new access tokens, which can be done without any user interaction. You need to do some preparation work to retrieve the refresh token though.
Following the steps describing the Authorization Code flow, you first need to direct the playlist's owner to a URL on Spotify's account server.
The documentation contains the following example URL:
GET https://accounts.spotify.com/authorize/?client_id=5fe01282e44241328a84e7c5cc169165&response_type=code&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback&scope=user-read-private%20user-read-email&state=34fFs29kd09
Simply replace the client_id and redirect_uri with your application's information. Also modify the scope parameter to match the scopes you need, which from my understanding of your use case is playlist-read-private,playlist-modify-private,playlist-read-collaborative since you want to be able to read and modify all of the user's playlists. Supplying state is not required.
Using spotify-web-api-node you can generate this URL using the createAuthorizeURL method, but since you're only doing this once it's unnecessary to write code for it.
Instead, simply open the URL in your browser.
If done successfully, you'll be taken through a little login dance where your application asks for your permission to read and modify your playlists. When this is completed, Spotify's account service will redirect the browser to your redirect_uri URL with a code query parameter included as described in step 3 in the Authorization Guide.
However, since you're only doing this once, it would be enough to start a webserver on your own machine, set your application's redirect_uri to your localhost, and complete the login flow. Have a look at web-api-auth-examples for a ready-made node.js application that fires up an express server and reads the authorization code.
Once you've got the code, you can trade it for an access token using cURL as it's done in step #4 in the Authorization Guide, or use the code in the web-api-auth-examples repository.
Finally, with the tokens retrieved (step #5), you can start to use the Web API with the access token, and get a new one when it expires using the request in step #7.
spotify-web-api-node has a helper method to refresh the token. Search the main documentation for the refreshAccessToken method.
This use case is slightly mentioned in the FAQ section of the Authorization Guide.
As you said, you need to obtain a refresh token using the authorization code flow. For that you will need to carry out the OAuth process using your user account, the client_id of the app you have registered, and the scopes you need (it will vary depending on whether the playlist is private or public). Then, take the refresh token you have obtained and the client secret key of your app, and you can obtain access tokens without the need of the login form.
This related StackOverflow question might help too Spotify automated playlist management with PHP back-end and rate limits