We have a Oracle Sales Cloud to DocuSign java based integration, which was implemented 3 years ago. As DocuSign has mandated OAuth 2.0, we need to make changes to our existing code.
But first we will need the ‘integration key’ and ‘secret key’ for the existing DocuSign integration user. Though we have the username and password, we are still not able to login because DocuSign is sending verification email to the integration user, and we don’t have access to that email. None of the people who implemented this java integration is working anymore in our company.
So this is a road block for us!
Your suggestion is greatly appreciated. Thanks.
The Client ID (same as the integration key) owns the private/public key pair, not the user being impersonated.
The user who is being impersonated needs to approve (consent to) the impersonation. If you don't have access to the email inbox you can either:
Get access (or use a different to email)
Use administrative consent to grant consent. Administrative consent is granted by the DocuSign account admin, not by the individual. See my blog post
Related
I'm in the process of converting an internal C# API that uses a legacy SOBO integration to one that uses OAuth 2.0 as required by DocuSign. The legacy application makes all requests to DocuSign using DocuSign credentials of an application user (a non-person) and injects SOBO data (email address) in the appropriate header when we need to generate an embedded sending URI and have it appear that the envelope was sent by a real person without using their credentials.
I have successfully converted another (non-SOBO) internal API using JWT grant, but I do not know how replicate the SOBO dependent workflow. Have read Matt King's article "From the Trenches: OAuth 2.0 and the new SOBO", but still a bit confused. I know how to extract userId from email address as mentioned in the article, but not sure what do with it. Similar to my legacy application, I am using a application user to get consent and ask for JWT token without prompting internal users for their consent. Is this still possible using OAuth 2.0?
Happy to help here. Once you've retrieved the user's apiUserName / userId you'll want to add it into the JWT assertion's sub line.
When you go to generate the token, if consent has not been provided by or for the user, our system will send back an error of "Consent_Required." See https://www.docusign.com/blog/developers/oauth-jwt-granting-consent for different methods of granting consent.
For individual consent, the user needs to go to a specific URL containing your clientId, redirectUri, and some additional scopes. If they hadn't previously consented to the scopes in your OAuth request they will be prompted to do this once. You can confirm consent has been applied by having them visit the same link afterwards, which will send them directly to your redirectUri.
Domain consent works a little differently -- you need to have an organization, a claimed domain, and the users you're providing consent on behalf of need to have an email address that is part of that claimed domain.
Happy to connect and walk you through it -- if you can open a ticket at support.docusign.com and in the details request they reach out to me I should be able to have the case transferred and work with you from there.
Regards,
Matt King
I want to enable permissions for a particular user using password grant type.
But that user is MFA enabled as per my tenant policies.
Is it still possible to generate access token for that user from behind a service for only delegated permission ?Thank you
Aarushi
There is a good post from a few years back on why not to use ROPG, one of which is that it will only ever support a single form of login (not MFA):
Resource Owner Password Grant Problems
OAuth 2.1 will Drop Support for ROPG
Maybe if you explain your requirements we can suggest a solution that uses a more future facing flow ...
I'm trying to authenticate my user on my site using StackExchange OAuth API.
Everything works fine when the user signs up for the first time. At this point, I get the "access token", which I save in my DB.
But the next time the user signs in, access token value is actually different to the previous one. Is it supposed to be like this?
If then, how do I check for existing users who already have signed up using StackExchange?
I can get the user's information by giving a specific site name (e.g. 'stackoverflow'). But what if I don't have that information and I need to check that the user has already signed in via StackExchange?
Is there a "user" information that I can get given an accessToken?
The StackExchange OAuth implementation is not meant to authenticate users to 3rd party applications but instead it is about authorizing those 3rd party applications to get access to the StackExchange API.
The access token that you get is not a token that represents a currently logged-in user, it represents the permission to access the API on behalf of the user gave it to your application. This is the classical confusion about the scope of OAuth 2.0 which is discussed in detail here: http://oauth.net/articles/authentication/.
In summary: you can't use OAuth or the StackExchange access token to authenticate users.
StackExchange does support the OpenID protocol to facilitate the purpose that you are looking for, see https://openid.stackexchange.com/. The downside of that is that OpenID is a deprecated protocol, superseded by OpenID Connect. OpenID Connect is an authentication protocol that is actually built on top of OAuth 2.0, but is not yet supported by StackExchange.
I have my APP ID / APP Key and using the PHP sample file I authenticate against our install of D2L. I receive back the UserID and UserKey to the sample page. I authenticate against the system with my Admin userid and password at this point, not a specific account for this. I can perform the WhoAmI and a couple other things, however, I'm looking at how I can authenticate a specific user into the system at this point for SSO? We have a custom portal and I authenticate users from it to our Angel LMS now. I'm looking to do that for D2L, authenticate the user that the portal has already validated and pass them into D2L My Home page. I have worked with a variety of API's over the years, but this one has been difficult and documentation seems limited. Any help would be appreciated.
If I understand you correctly, currently your LMS users employ the Angel LMS as an identity provider (i.e. it actually authenticates the users), and then the D2L LMS consumes that IDP's service in order to authenticate a user? D2L does support use of the Valence Learning Framework APIs when the D2L LMS is using another, third-party, service as an IDP, but the environment configuration can be somewhat tricky.
Essentially, the entry point for API authentication (the first step that an API client must take to get a set of user keys) calls an URL in the D2L LMS that then re-directs to the procedure to log in the user, passing a ?target= parameter containing the callback URL that the calling client provided when first requesting the user tokens.
Thus, in order for the SSO using a third party IDP to work for an API caller, that target parameter needs to be passed along in each stage of the user authentication chain, properly URL-encoded at each stage. The Valence documentation does provide an overview of this process.
If your particular LMS needs differ from one of the standard user-authentication scenarios, it's probably good to have your LMS Admins contact D2L's customer support desk and open an incident with them, specifically explaining that you would like to ensure that your LMS environment using third-party user authentication can be properly set up to use the Valence Learning Framework APIs.
We want to use Google Doc API to generate Document (In our own business account) when our end users do some actions on our site.
The problem is that we've tried to implement the OAuth 2.0 protocol, as suggested in the v3.0 protocol documentation. The apiClient::authentication method do a redirection. This is a major problem because our users doesn't know the access to our own business account.... and we don't want to give them access anyway ;)
(In other word, we're not creating an application that allow our users to edit their own data, but to interact with our data, like a database.)
I've read that the point of OAuth 2.0 was to avoid that we manage the credential of our users. I'm personally O.K. with the concept, but in our case, we don't want to get authenticated in the google account of our users ...
So, what would be the best approach to get a valid authentication without any interaction from the end user ?
What you describe is not how 3-legged OAuth was designed to be used.
3-legged OAuth is all about delegated authentication where a user (who knows his password) can grant limited and revokable resource access to application. That application never sees the user's password. There is a bunch of work involved to safely allow the application to impersonate the user.
What you probably want is to use the (2-legged) OAuth flow, where the consumer_id/consumer_secret credentials are embedded in your application. Here your application is not impersonating your end user and there would be no browser redirection involved.
Here's some further info on using 2-legged OAuth in Google Apps:
http://googleappsdeveloper.blogspot.com/2011/07/using-2-legged-oauth-with-google-tasks.html
And this is a good description of 3- vs 2- legged OAuth:
http://cakebaker.42dh.com/2011/01/10/2-legged-vs-3-legged-oauth/
You will need to use a SERVICE ACCOUNT. Basically you are hard coding access to this account into your server application. Then you use sharing to give access to the to account for the content you want. For example you can share a Google Doc or an Analytics profile with the SERVICE ACCOUNT.
Here is a complete example implementation of setting up a service account, logging and and then using it.
Updated 2018-12-12: https://gist.github.com/fulldecent/6728257
Why not get one OAuth authorization for your business account and have all users use that account. Since it sounds like you want everyone accessing the data for one account, the details can be hid from the end user.
The access token would be shared by all users and they would all hit the same account back end without any authorization for each user's own account.