I have checked Docusign Request the Authorization Code related documentation and set all the settings on Docusign Admin. But when I run the below url in the browser it wants login details and accept screen. My query is how can I skip this login and accept steps. Here is the request url
https://account-d.docusign.com/oauth/auth?response_type=code&scope=YOUR_REQUESTED_SCOPES&client_id=YOUR_INTEGRATION_KEY
&state=YOUR_CUSTOM_STATE&redirect_uri=YOUR_REDIRECT_URI
You cannot skip this login page if you are using the authorization grant flow as this is part of the oauth protocol security. To get a token, you need to authenticate (or your customer/user would need to). This token is typically valid for 8 hours and a cookie is stored on the device which means you won't be asked again to login for the next 8 hours, but you do need to do this initially.
Related
I am struggling to get access tokens from .net console app context. I am getting them and they work, but they expire too fast.
I checked the other two threads in stackoverflow, in both answers it was stated, that once you get the consent per IK and per user, you don't have to do it anymore. However once I get the bearer token from the return_url and use it to request the access tokens a few minutes after the bearer was obtained, I get response with "error_description:expired_client_token".
So me manually obtaining bearer from the browser in order to set it as a parameter (again manually) in my console app and having the bearer expiration duration just a few minutes doesn't match "Consent is needed only once, ever, per a specific integration and a user".
I see that docusign uses cookies' values/expiration and can probably reverse engineer a GET call to account-d.docusign to get the bearer from the console app context, but that's not what I'd expect from an API provider.
For reference I'm using the following URL to manually get the bearer from the browser:
https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature&client_id=d69848a8-2a93-4d03-ab40-bcabda8a7e8f&redirect_uri=https://www.docusign.com
But as stated above, it does expire in a few mins to get the aforementioned error_description
Thank you in advance!
Response type = code is the Authorization Code grant flow.
But for a console app where the implementation of the application is downloaded to the user's machine, the Implicit grant flow must be used.
This is because the Authorization Code grant flow includes a second API call, from the app to the OAuth Service Provider. This second call is used to exchange the authorization code for an access token. This second call requires a secret value, but there is no guaranteed method for keeping a secret in an app that's downloaded to the user's machine.
The Implicit grant flow immediately returns the access token to your app for use in calling the API.
Using the Implicit grant with a console app
Here are the steps. I also discuss this use case in my Electron React apps post.
The key is to use Private-Use URI Scheme Redirection to handle the authentication and receive the resulting access token. See RFC 8252 ยง7.1
Your app registers a http private scheme such as com.example.name_of_my_app with the operating system (windows). This way, any URL like com.example.name_of_my_app://app will be directed to your application to be processed.
Configure your DocuSign client id (integration key) to enable implicit grant and to use com.example.name_of_my_app://app as a return URL. No secret is needed.
When a user wants to authenticate with DocuSign via your app:
Your app initiates the implicit grant flow with the DocuSign OAuth Service Provider by "opening" the URL
https://account-d.docusign.com/oauth/auth?response_type=token&
scope=signature&client_id=xxxx-xxxx&
redirect_uri=com.example.name_of_my_app://app
Windows should open the default browser to the URL. The result will be the authentication page from DocuSign. Your app should NOT open a web view or similar. The operating system's browser should be automatically activated.
After the authentication is done, consent will be requested if needed.
Next, DocuSign will respond to the browser with a redirect to the redirect_uri. This will trigger your application and give your application the access token needed for API calls to DocuSign.
For some operating systems, your app can close the browser window that was created as a result of its URL open.
See the blog post for more info.
Added
As Ben says, your specific problem is that the authorization code that you receive back in the first step of the Authorization Code grant flow only lasts a minute or so. During that time, you exchange it for an access token (which lasts for 8 hours). But as I say above, you should not be using the authorization code grant flow, you should be using the implicit grant flow.
The token in the response only lasts about 2 minutes. Its true that consent is only needed once, but your problem is not consent.
Background:- I'm trying to implement the Implicit Grant REST API of DocuSign.
According to the documentation provided by DocuSign:-
After consent has been granted, the Authentication Service verifies that the client application is valid and has access to the requested scope. If so, it redirects the access token to the provided callback URI in a hash fragment.
The response contains the following hash fragment parameters:
http://localhost/#access_token=eyJ0eXAi.....9LyiFrUqvdw&expires_in=28800&token_type
Problem statement:-
After redirection we are trying to read the access token from the hash fragment of url section, but we are facing below issue:-
We are trying to open docusign window through iframe, we are getting the below error
Refused to display
https://account-d.docusign.com/oauth/auth?response_type=token&scope=signature&client_id=cab75309-6eb3-4969-a15d-fff35513e179&redirect_uri=https://www.sirionlabs.com/
in a frame because it set 'X-Frame-Options' to 'sameorigin'
So we tried to login to docusign app in another browser tab and then we are not able to read access token from the user, though we are getting the token printed on browser console.
How can we read the token received after login-in to Docusign service, so we can redirect that token to our app for further processing?
You cannot use an iframe for DocuSign authentication.
This is a security concern.
Users must see the URL at the top to know it's DocuSign and secure etc.
Please use a different window or redirect.
I'm following this tutorial to get the track list from my Discover Weekly playlist. The tutorial mentions that I need to get an OAuth token for my own account before requesting the playlist info. This is done by going to a random Console page and click on 'Get token' at the end of the page (which requires me to log into my Spotify account and approves the Console to access my account data).
However, I want to acquire this token programmatically, instead of manually clicking on 'Get token' and logging into my account every time I need this token. What I have is:
My Spotify user ID (from my Account page)
The Spotify client ID for an application I just created under Spotify for Developers
The client secret for this application
Basic knowledge of how to send GET and POST requests (using Python's requests library)
How can I get an OAuth token, or at least generate a new token each time, using some of these above
information?
It depends on what you're trying to do. If all you want is a token to query the api to lookup songs/artists/etc., then you can use the Client Credentials auth flow that doesn't require any user input. All you need to do here is exchange your client ID and secret for an access_token that you'll use in subsequent requests.
If you want access or change certain user information, you'll have to use one of the two other flows on the same spotify authorization page. You'll need to pass a list of scopes with this request, directing the user to a spotify-url-based authorization page, and be able to give it a redirect url that will handle the receiving of the access_token object once the user logs in to the spotify page.
I don't think there's a way to implement one of these flows where you need to request user scopes without having some sort of web server running to accept the redirect passed into the spotify auth url and then save the given token.
After looking at the link you posted for spotify's console pages, it looks like you can use any of those API requests to generate a token including the scopes you want. All it's doing is performing the normal authorization flow in the background, skipping the step where it returns a secret to you that your server that you can then exchange for an access_token and refresh_token. Using the spotify console pages seems like an easy quick way to get scripts or prototypes running without having to deal with setting up your own webserver.
Our web application procedure is like
The docusign account user needs to use his/her own credentials to log in our application and can see the documents in our application sent him by our client.
For this how can we proceed with docusign .
any procedure with restapi will be helpful for us.
Yes this is a common workflow- you need to use OAuth which let's you accomplish this in a secure way so that your application never sees the user's account credentials (instead it gets a valid access token to use on their behalf).
Since you have a web app you should use the Authorization Code Grant flow, the steps for Auth Code grant are:
Request the Authorization Code
Obtain the Access Token
Retrieve User Account Data
NOTES
In Step #1 your app needs to construct the proper authorization URI including query parameters and direct the user there so they can sign in using the standard DocuSign login. Once the user logs in and grants consent they are redirected back to your app along with an authorization code as a query parameter.
In Step #2 you use the authorization code retrieved from the first step to exchange for an access token. This is an actual API call (as opposed to simply redirecting the user like step 1).
Step #3 is another API call your app needs to make to finally get the user's account data and base_uri where you can then start making requests on their behalf.
For more info see the following guide from the DS Dev Center:
Authorization Code Grant
I'm trying to wrap my head around oauth with a React Native app and a separate NodeJS/Express API backend. I understand https://github.com/adamjmcgrath/react-native-simple-auth offers authentication for a React Native app and http://passportjs.org/ offers authentication for a NodeJS backend. I'm unsure how to connect these two for authentication for login and access to the API.
I'd like users to login to the React Native app either by email and password or via Facebook/Twitter/Google. Once logged into the app, what do I send to the API to make sure they are authenticated and have access to a specific route?
Here is an example flow to login and see the logged-in user's settings:
User logs into React Native app via email/password or Facebook/Twitter/Google.
User is authenticated
App makes request to GET /api/settings
API verifies user is authenticated and returns that user's settings or API verifies user is not authenticated and returns a 403.
There's a whole lot to this question, so much so that it wouldn't all fit in a single SO answer, but here's some tips and a general outline that should broadly fit into what you want to accomplish.
OAuth2 Authorization
From the sounds of it, you are interested in using OAuth 2 to provide social login authorization, and would like to do first-party authentication as an alternative with an email and password. For social logins you will end up using the OAuth 2 Implicit flow to retrieve an access token, which is a widely recognized pattern. Because you are also looking to authenticate users with an email and password, you may want to familiarize yourself with OpenID Connect, which is an extension of OAuth 2 and which explicitly supports authentication in addition to authorization.
In either case, once your user has either submitted an email/password combo or granted permission through the social identity providers, you will receive in response an access token and (optionally) an ID token. The tokens, likely a JWT (JSON Web Token, see jwt.io) will come across as a base64 encoded string that you can decode to inspect the results of the JWT, which will include things like the ID of the user and other details like email address, name, etc.
For more info on the different types of flows, see this excellent overview on Digital Ocean.
Using Tokens for API Authentication
Now that you have an access token, you can pass it along with all requests to your API to demonstrate that you have properly authenticated. You'll do this by passing along the access token in your HTTP headers, specifically the Authorization header, prefacing your base64-encoded access token (what you originally received in response to your authorization request) with Bearer . So the header looks something like this:
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJh...
On your API's side, you will receive that token, decode it, and then verify the ID and claims in it. Passed as part of the token in the sub property will be the subject, or ID of the user making the request. This is how you identify access and start to do things on your API side with the respective user's rights, perms, etc. It is also important that you validate the access token once you receive it on your API side, to ensure it wasn't spoofed or hand-crafted.
How it looks in RN for Implicit flows
Here's what the general process looks like in React Native for OAuth 2 Implicit flows, which is what you'll use for social identity providers:
User taps one of your social login buttons on React Native UI
Your code that responds to the buttons will build a request URL to those providers, depending on what each wants (because it differs slightly).
Using the Linking API in RN, you will open up that URL in a browser on the device which sends the user off to the social provider for them to do the login/authorization dance.
Once complete, the social provider will redirect the user to a URL you provider. On a mobile device, you will use your own custom URL scheme to move the user from the web view to your app. This scheme is something you register as part of your app, such as my-awesome-app://, and the redirect URL you pass to the social provider could look like my-awesome-app://auth_complete/. See the Linking API docs for how to configure these URL schemes and deep linking.
In the handler for that new URL scheme/deep link, you'll get the tokens passed as part of the URL. Either by hand or using a library, parse out the tokens from the URL and store them in your app. It's at this point that you can start inspecting them as JWTs, and pass them along in the HTTP headers for API access.
How it looks in RN for Resource Owner Password Grant flows
You have the option for your email/password combo for your own accounts of either sticking with the Implicit flow, or switching to the Resource Owner Password Grant flow if your API and app are trusted by each other, meaning that you are making both the app and the API. I prefer the ROPG flow on mobile apps where possible because the UX is much nicer--you don't have to open up a separate web view, you just have them type in their email and password into UI elements directly in the app. So that being said, here's what it looks like:
User taps the email/password combo login button, and RN responds with a UI that includes TextInputs for the email and password
Build a POST request to your authorization server (which may be your API, or may be a separate server) that includes the properly crafted URL and body details that passes along the email and password. Fire this request.
The auth server will respond with the associated tokens in the response body. At this point you can do the same thing previously done in step 5 above, where you store the tokens for later use in API requests and inspect them for relevant user information.
As you can see, the ROPG is more straightforward, but should only be used in highly trusted scenarios.
At the API
On the API side, you inspect for the token in the Authorization header, and as mentioned previously, and if found you assume that the user has been authenticated. It is still good security practice to valid and verify the token and user permissions. If there is no token sent with the request, or if the token sent has expired, then you reject the request.
There's certainly a ton to it, but that provides a general outline.