Clarification on REST APIs around user management in an account - docusignapi

I recently created a docusign developer account and integrator key and was playing with docusign REST APIs and had some questions
I can retrieve full list of users under my account by using following REST call.
https://demo.docusign.net/restapi/v2/accounts/<accountid>/users?additional_info=true
However if I try and retrieve a specific user (other than the one I am passing in my X-Docusign-authentication) header i get http 400 error with message that the "Invalid UserId. UserId specified in request uri does not match authenticated user"
https://demo.docusign.net/restapi/v2/accounts/<accountid>/users/0d51a699-b17a-48b7-95b6-1e9e9806deb6
In both cases i am sending the following header.
X-DocuSign-Authentication: <DocuSignCredentials><Username>{0}</Username><Password>{1}</Password><IntegratorKey>{2}</IntegratorKey></DocuSignCredentials>
I am surprised that while I can read all users fine, I cannot just read one specific user. Surely it doesn't seem like this is security thing since I can read the user via one API but not the other using the same auth token.
What am i missing?
I guess I can go the route of SOBO (Send on behalf of functionality), but I wanted to confirm if above behavior is expected.
Update#1
: I went the SOBO approach and now i get a different error (USER_NOT_ACCOUNT_ADMIN) as shown below
GET /restapi/v2/accounts/{accountid}/users/0fe29a55-5564-42a9-b09d-cbe699db13dd HTTP/1.1
Authorization: bearer {token for authenticating user}
X-DocuSign-Act-As-User: {operating user's email}
Accept: application/json
Host: demo.docusign.net
Connection: Keep-Alive
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
Content-Length: 100
Content-Type: application/json; charset=utf-8
Date: Thu, 17 Oct 2013 21:18:32 GMT
Strict-Transport-Security: max-age=7776000; includeSubDomains
{
"errorCode": "USER_NOT_ACCOUNT_ADMIN",
"message": "User is not an account administrator."
}
I also tried the second SOBO approach of getting a oauth token for the operating user but got back http 400 error with below message
{
"error": "invalid_request",
"error_description": "An OAuth2 error occurred."
}
So while i can get an oauth token for the autheitcating user, i am not able obtain oauth token for the operating user or act on their behalf.
I have made sure that authenticating user is "Account Administrator" and has both "apiAccountWideAccess" and "•allowSendOnBehalfOf" set to true. The only thing set to "false" is "canSendAPIRequests". My account id in sandbox environment is "601565a7-e9c7-463b-9d7c-622aed905ea8" Any ideas?
Update#2
Instead of generating oauth tokens on behalf of both authenticating user and operating user, i tried passing below header and i can finally get another user's profile and update another user's profile.
X-DocuSign-Authentication: <DocuSignCredentials><SendOnBehalfOf>{operating userid}</SendOnBehalfOf><Username>{authenticating userid}</Username><Password>{authenticating user's password}</Password><IntegratorKey>{developer's integrator key}</IntegratorKey></DocuSignCredentials>
Great!
So here is status of what works and what doesn't.
Works with no SOBO header anywhere
GET /restapi/v2/accounts/357938/users?additional_info=true // Read all users
GET /restapi/v2/accounts/357938/users?email=someshchandraatwork#gmail.com&additional_info=true // Read single user by email
POST /restapi/v2/accounts/357938/users // Add users
DELETE /restapi/v2/accounts/357938/users // Close users
*Works with SOBO in X-DocuSign-Authentication header
PUT /restapi/v2/accounts/357938/users/74a021e1-3090-4843-b9ab-cceb7cd119f4/profile // Update user's profile
GET /restapi/v2/accounts/357938/users/74a021e1-3090-4843-b9ab-cceb7cd119f4/profile // Read user's profile
Still doesn't work with or without SOBO**
GET /restapi/v2/accounts/357938/users/74a021e1-3090-4843-b9ab-cceb7cd119f4/settings
GET /restapi/v2/accounts/357938/users/74a021e1-3090-4843-b9ab-cceb7cd119f4
In both not working cases i get following error
Without SOBO i get error that userid doesn't match autheitcating user.
With SOBO i get error than user is not an account admin
I would very much appreciate any help in resolving the not working cases. I can provide more detaisl as needed.
Secondly I want to implement a scenario where I can deactivate a user in an account so they can no longer log into docusign. And subsequently I would like to enable that user back again with same permission that they had before they were disabled.
I see that user has a "userStatus" field and was wondering if I can use that to de-activate the user and then re-activate if needed. If this is supported then what value would correspond to deactivating the user?
The other thing I note is that on DELETE a user, the user is only soft-deleted since I can still query the user with the status "CLOSED". That would solve my "deactivate" problem. However I was not sure if there is a way to reactivate them back again after the user has been "closed"?

I believe this might be an account administration issue. I'm not sure why but I looked at your account settings from DocuSign's side and I saw the "Send on Behalf of" was not checked on your account- which is weird since it seems you have access to the setting in your Console -> Preferences settings.
But in either case I'm wondering if the setting I just enabled on your account has solved your issue, as it might have.
I'm also not sure about the user info portion of your question, let me see if I can come up with anything for that and I'll edit my answer once I do.

In reply to Erign's post above.
Anyone who is an account admin should be able to modify/add/delete users in an account. I'm not sure if your SOBO steps are correct though, can you confirm that you are following THESE STEPS exactly? If so, at which step do you run into issues or get an error?– Ergin5 mins ago
Yes i am following those steps. I am able to generate oauth token for the autheitcating user , but get an error when doing the same for the operating user. Below are my request and responses.
1. REQUEST FOR AUTH TOKEN FOR AUTHENTICATING USER
POST /restapi/v2/oauth2/token HTTP/1.1
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Host: demo.docusign.net
Content-Length: 139
Expect: 100-continue
Connection: Keep-Alive
grant_type=password&client_id={integratorykey}&username={authenticating user's email}&password={authenticating user's password}&scope=api
RESPONSE
HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Length: 100
Content-Type: application/json; charset=utf-8
Date: Thu, 17 Oct 2013 22:57:26 GMT
Strict-Transport-Security: max-age=7776000; includeSubDomains
{
"access_token": "{authenticating user's token}",
"token_type": "bearer",
"scope": "api"
}
2. REQUEST FOR AUTH TOKEN FOR OPERATING USER
POST /restapi/v2/oauth2/token HTTP/1.1
Authorization: bearer {authenticating user's token}
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Host: demo.docusign.net
Content-Length: 137
Expect: 100-continue
grant_type=password&client_id={integratorykey}&username={operating user's id}&password={empty}&scope=api
RESPONSE
HTTP/1.1 400 Bad Request
Cache-Control: no-cache
Content-Length: 87
Content-Type: application/json; charset=utf-8
Date: Thu, 17 Oct 2013 22:57:29 GMT
Strict-Transport-Security: max-age=7776000; includeSubDomains
{
"error": "invalid_request",
"error_description": "An OAuth2 error occurred."
}

Related

instagram basic display API get request not working?

I'm trying to do a basic get request based on the short-lived token recieved from a previous request to instagram. I know the short-lived-access-token is valid.
The account i'm testing with is a test user and the app is in development mode at facebooks end. Furthermore, the app review is currently pending but i dont think that's the issue since the account i'm testing is a test account and again - the login feature is set to development mode.
When i do the request based on the documentation:
https://developers.facebook.com/docs/instagram-basic-display-api/guides/long-lived-access-tokens/
i get the following response with status code 400:
Sorry, this content isn't available right now
based on this request format:
https://graph.instagram.com/access_token
?grant_type=ig_exchange_token
&client_secret={instagram-app-secret}
&access_token={short-lived-access-token}
Here is the full response:
HTTP/1.1 400 Bad Request
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
Vary: Origin
Content-Type: application/json; charset=UTF-8
WWW-Authenticate: OAuth "Facebook Platform" "invalid_token" "Invalid OAuth access token."
Access-Control-Allow-Origin: *
Strict-Transport-Security: max-age=15552000
Pragma: no-cache
Cache-Control: no-store
Expires: Sat, 01 Jan 2000 00:00:00 GMT
x-fb-request-id: Al1knRjoI2Qw1XEVlh4b3Ku
x-fb-trace-id: GasPh1zh4bl
x-fb-rev: 1004118369
X-FB-Debug: 73PsZ2YPe6C2obr8nIdox2r2YOtNoVsuva4y2rRLvd70l06oV8kfdjOzLRhPvLDvpsmc1+5gP42Hc4Pi4AUHLw==
Date: Fri, 16 Jul 2021 04:19:09 GMT
X-FB-TRIP-ID: 1512268381
Connection: keep-alive
Content-Length: 45
Sorry, this content isn't available right now
Had this problem too, but fortunately stumbled upon the solution. What was missing for me that I wasn't requesting the instagram_graph_user_profile permission when authorizing the user.
This permission is listed as being required for the access_token endpoint, and for me made the difference between getting "Sorry, this content isn't available" and a long-lived access token.
i.e.
https://api.instagram.com/oauth/authorize
?client_id={app-id}
&redirect_uri={redirect-uri}
&scope=user_profile,user_media,instagram_graph_user_profile
&response_type=code
Exchanging access_token can be tricky sometimes. Let me walk you through another way to get the access_token.
First, we make a GET call to get the auth code. Scope depends on the permission given to the Test app.
https://www.facebook.com/v11.0/dialog/oauth?client_id={app-id}&redirect_uri={your_redirect-uri}&auth_type={rerequest}scope={email}
Now, Your Test App needs login access which further gets redirected to the URL mentioned in the test app. The URL consists of code. Copy the code and don't include #= part.
To get the access token now we make another GET request.
https://graph.facebook.com/v11.0/oauth/access_token?client_id=${CLIENT_ID}&redirect_uri=${REDIRECT_URL}&client_secret=${CLIENT_SECRET}&code=${oauth_code}
This gives you access_token. Copy the access_token and paste that in Access Token Debugger link. You will find out that this comes with no expiry date.

Azure OAuth to function app issues

I have a very basic function app that takes a GET and returns some static text. Eventually I would like it to write a POST body to a queue but to keep it simple the function just returns text. If I keep auth off, I can load the url and get a response in my browser or postman. If I enable aad auth within the function app and create a simple app reg then goto the site in my browser I get prompted for auth and I can login interactively; no worries so far.
I would like to access the function using a secret key for application usage with no interactive login, so within the app reg I go to Keys and generate one. This is where my problems start. If I use postman and configure oauth using my app id and key I can get a token, I have verified this also by doing a POST to https://login.microsoftonline.com//oauth2/token directly and noting the bearer token reply. However when I try an access my function app using the bearer token (either by manually adding an Authorization header or letting postman add it from the oauth 2.0 form) I am always denied with a 401 stating 'You do not have permission to view this directory or page.' when I do a GET to my function app. Can someone point me in the right direction? Thanks in advance.
Example reply from login url
{
"token_type": "Bearer",
"expires_in": "3599",
"ext_expires_in": "0",
"expires_on": "1525312644",
"not_before": "1525308744",
"resource": "https://<siteaddress>.azurewebsites.net/",
"access_token": "eyxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx..etc..."
}
Response from get against function app with token
GET /api/t2 HTTP/1.1
> Host: <sitename>.azurewebsites.net
> Authorization: Bearer eyxxxxxxxxxxxxxxxxxxxxxxxxxxxx.....etc....
> Accept: */*
< HTTP/1.1 401 Unauthorized
< Content-Length: 58
< Content-Type: text/html
< WWW-Authenticate: Bearer realm="<sitename>.azurewebsites.net" authorization_uri="https://login.windows.net/<tenantid>/oauth2/authorize" resource_id="<app reg id>"
< X-Powered-By: ASP.NET
< Date: Thu, 03 May 2018 01:12:43 GMT
I believe you're mixing Azure AD integration with function keys (API key authorization).
The latter is a self-contained authorization mechanism and works by appending
?code=<func-key-from-portal>
to the function URL, or by passing a
x-functions-key: <func-key-from-portal>
header with every request to the function. No OAuth is involved when using function keys.
Example:
GET /api/get-issues HTTP/1.1
Host: {funcapp}.azurewebsites.net
User-Agent: ajax-library-of-the-day
x-functions-key: rkW0PqT.....zcUBQ==
or
GET /api/get-issues?code=rkW0PqT.....zcUBQ== HTTP/1.1
Host: {funcapp}.azurewebsites.net
User-Agent: ajax-library-of-the-day

DocuSign Integrator Key is not found or disabled

I created a new developer account on DocuSign, generated the integrator key. Now i am trying to submit a GET request for retrieving account information but I keep getting error message "Integrator key is not found or disabled"
Below is my request which I am submitting using fiddler"service integration authentication" :
Raw http request
GET https://www.docusign.net/restapi/v2/login_information HTTP/1.1
X-DocuSign-Authentication: {"Username": "MyEmail","Password": "MyPassword","IntegratorKey": "IntegratorKeyCreatedFromAdminConsole"}
Host: www.docusign.net
Response:
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
Content-Length: 128
Content-Type: application/json; charset=utf-8
X-DocuSign-TraceToken: 4694b892-09cb-41aa-b5fa-307d226e9dd0
Date: Tue, 10 Jan 2017 16:26:33 GMT
Strict-Transport-Security: max-age=31536000; includeSubDomains
{
"errorCode": "PARTNER_AUTHENTICATION_FAILED",
"message": "The specified Integrator Key was not found or is disabled."
}
Thank you for your help!!
The URL you are trying to access is a production URL. Your integrator key only exists in DEMO, so update the URL to:
https://demo.docusign.net/restapi/v2/login_information
DocuSign should update their documentation at https://docs.docusign.com/esign/ When they talk about getting the baseURL they specify to go to the production url. They don't mention they have a URL for their demo system. Also their CURL sample does not work for DOS CURL. One has to use " and escape the json " with \ for example
curl -H "X-DocuSign-Authentication:{\"Username\": \"bob#example.com\",\"Password\": \"xxx\",\"IntegratorKey\": \"your_key\"}" https://www.docusign.net/restapi/v2/login_information

Getting a DocuSign access token for an SSO user

I'm trying to get access tokens for users in order to use the iOS SDK for integrating in-person signings.
Our DocuSign users are set up as Single sign-on. We have a non-SSO, API user configured with the user settings apiAccountWideAccess and allowSendOnBehalfOf enabled.
I request an access token for the non-SSO, API user as follows:
POST /restapi/v2/oauth2/token HTTP/1.1
Host: demo.docusign.net
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
grant_type=password&client_id=<client_id>&scope=api&username=<useranme>&password=<password>
This results in the following response:
{
"access_token": "<access-token>",
"token_type": "bearer",
"scope": "api"
}
I then use the access token from the above response to try to get an access token for an SSO user as follows:
POST /restapi/v2/oauth2/token HTTP/1.1
Host: demo.docusign.net
Authorization: Bearer <access-token-from-response-above>
Accept: application/json
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
grant_type=password&client_id=<client_id>&username=<email-address-of-sso-user>&password=&scope=api
This results in the following response:
{
"errorCode": "UNSPECIFIED_ERROR",
"message": "Object reference not set to an instance of an object."
}
I'm following the documentation here (Obtaining access_tokens for Other Account Users).
Is it possible to get access tokens for the REST API on behalf of SSO users?
Unfortunately you can not use the API as a SSO enabled user at this time.
If you need to use the API as a SSO user, you have to have that user on the SSO Exempt list.
Generally integrations use Send On Behalf Of to authenticate as the API user (that on the exempt list) and makes the calls on behalf of the users who have SSO enabled.
The error doesn't indicate the actual issue and I've filed a bug with DocuSign Support to get that portion addressed.

Cannot access OpenId UserInfo endpoint on Azure (AADSTS90010: JWT tokens cannot be used with the UserInfo endpoint)

I'm trying to access the OpenId UserInfo endpoint for a user on an Office365 Azure tenant, with the following GET:
GET https://login.windows.net/common/openid/userinfo HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJ(...remainder deleted for brevity...)
Host: login.windows.net
The response fails with "400 Bad Request", and a more specific error "AADSTS50063: Credential parsing failed. AADSTS90010: JWT tokens cannot be used with the UserInfo endpoint"
HTTP/1.1 400 Bad Request
Cache-Control: no-cache, no-store
Pragma: no-cache
Content-Type: text/html
Expires: -1
Server: Microsoft-IIS/8.5
x-ms-request-id: ef5c8a50-69b5-40f1-ac5f-9c0fc5180aa2
x-ms-gateway-service-instanceid: ESTSFE_IN_6
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains
P3P: CP="DSP CUR OTPi IND OTRi ONL FIN"
WWW-Authenticate: Bearer correlation_id="e5c613a0-0a21-40e1-9ef6- eacf77580608", error="invalid_request", error_codes="[50063, 90010]", error_description="AADSTS50063: Credential parsing failed. AADSTS90010: JWT tokens cannot be used with the UserInfo endpoint.%0d%0aTrace ID: ef5c8a50-69b5-40f1-ac5f-9c0fc5180aa2%0d%0aCorrelation ID: e5c613a0-0a21-40e1-9ef6-eacf77580608%0d%0aTimestamp: 2015-02-20 14:13:42Z", timestamp="2015-02-20 14:13:42Z", trace_id="ef5c8a50-69b5-40f1-ac5f-9c0fc5180aa2"
Set-Cookie: x-ms-gateway-slice=productionb; path=/; secure; HttpOnly
Set-Cookie: stsservicecookie=ests; path=/; secure; HttpOnly
X-Powered-By: ASP.NET
Date: Fri, 20 Feb 2015 14:13:40 GMT
Content-Length: 0
The bearer token used is a non-expired access token that works fine for other operations, such as retrieving Exchange emails.
Furthermore, when I use an identical GET to the openid userinfo endpoint at "https://www.googleapis.com/plus/v1/people/me/openIdConnect" (as part of a gmail access scenario), it works fine
Am I doing anything wrong here? Thanks for any help!
Some extra info:
-Already tried using the id_token instead of the access_token, but this makes no difference.
-the Oauth scopes used are "profile email"
-the resources requested are "https://outlook.office365.com/"
-the client application is a native app and has enabled all delegated permissions for both "Windows Azure AD" and "Office 365 Exchange Online"
The Azure AD user info endpoint does not support the use of the regular JWT access tokens at this time. Instead, you can acquire a user info specific access token by not specifying any resource in a request to the token endpoint. You can think of the user info endpoint as a resource in its own right, which requires a special token format.
For example, in the authorization code case:
GET request to https://login.windows.net/common/oauth2/authorize?... without a resource parameter, and acquire an authorization_code
POST request to https://login.windows.net/common/oauth2/token using the authorization_code, also without a resource parameter. Receive an access token for the user info endpoint.
GET request to https://login.windows.net/common/openid/userinfo passing the access token in the header as Authorization: Bearer AAAB(...rest of token...)

Resources