Develop Reference

DocuSign account cannot get JWT token

I have two accounts of DocuSign, both have the same config on the Setting section. But the first one even though expires of the trial still can send the envelopes. The second one gets invalid_request when I tried to get the JWT token base on client_id, user_id, and private_key.
Do we need to enable some config to allow it? Thanks in advance.

A couple of things:
Are you using a trial (login via www.docusign.net) or developer demo account (login via demo.docusign.net)? You should only use developer demo accounts while developing with DocuSign.
To get a free developer demo account click the link at the top right of the developer center page. Demo accounts do not expire, but their envelopes that are over 30 days old are automatically deleted.
invalid_request can be cause by a number of different issues. Additional information is available in the body of the response. Please see what it is and then edit your question to add the information.
Added
For JWT invalid_request errors, the recommended steps are:
Get the DocuSign code example running with JWT grant. For C#, this repo.
Once that works, you'll know that the problem is in your code, not in the settings of the integration key (the client id), the private key, etc.
Check that your computer's clock settings are correct--the timezone and the day/date. These are used by JWT.
Check that you are specifying a user's guid id to be impersonated. This is also referred to as a user's "API User Id"
Check the body of the API response for additional debugging information.
If you receive the error "consent_required", that is good news since it indicates that your JWT grant was correct, except that the person being impersonated hasn't yet granted consent to be impersonated. To fix, see this blog post.

Azure function + queue + Api

We have an problem while designing new API. The problem is that we have an MVC project and we want to connect it with new API. Our idea is simple (showed on graph): Graph here!
The problem is that we don't want 'ask' API for new authorization token (jwt authorization) every single time when we put message to queue. We invented that we can check if token not expired when we tried to put message to queue (ExpiredProperty in MVCApp memory). Anyway the situation may occur that token is valid to for e.g. 2018-01-01 00:00:10 and when we try to put message the date is: 2018-01-01 00:00:09.321 so for our program is still valid.
On API side we just take message from function decode this and check if token is valid (have api secret key, not expired) then if its ok we will put this message into AzureTable, but if it's not we don't know what we can do with this message.
We can't 'forget' this invalid message and also we can't let this message to be putted into db.
Have you got any idea how we can handle this?
Thanks for all responses.

How access token is validated for accessing protected resources in token based mechanism?

I want to do token based mechanism where I would be having either SPA or mobile apps supporting multiple clients.
Use case of my web service engine and my application:
My web application: Client will do registration of their application either SPA or mobile apps.They will get client id on registration.Only client id as secret key would be compromised in case of SPA or mobile apps hence I am just providing clientid.
Web service engine: Support multiple client with managing session of each user after login in to respective application of clients.
So let's say there are 2 client who have register their application in to my web application :
Client 1 : MyApp1
Client 2 : MyApp2
Now if MyApp1 have 2 users with John and Stephen and if they login in MyApp1 then i want to manage session for those users with token based mechanism. Now if John and Stephen wants to access protected resource then they can access only through valid accesstoken.
Same goes for MyApp2.
For token based mechanism I have seen lots of question referring to this below article only:
http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/
But the only confusion part in above tutorial and in most of the tutorial is after validating user name and password and generating access token. Does above tutorial is storing access token in server side cookie for validating accesstoken when request comes to access protected resource?
I am really confused here. I know accesstoken validation happens inside [Authorize attribute] but I am not getting without storing accesstoken how above tutorial is validating accesstoken.
My thought is like may be when request comes for accessing protected resources access token is encrypted or decrypted based on machine key attribute in webconfig and this is how access token is validated inside [Authorize] attribute but I am just not sure about this.

You can control what information goes inside a token. Look at the SimpleAuthorizationServerProvider class in the article:
var identity = new ClaimsIdentity(context.Options.AuthenticationType);
identity.AddClaim(new Claim("sub", context.UserName));
identity.AddClaim(new Claim("role", "user"));
Use the Claims to store anything you need regarding to the user, their username or roles and this is what happens in the article you referred to.
The token generated already contains that information about the user.
This is taken from the article :
The second method “GrantResourceOwnerCredentials” is responsible to
validate the username and password sent to the authorization server’s
token endpoint, so we’ll use the “AuthRepository” class we created
earlier and call the method “FindUser” to check if the username and
password are valid.
If the credentials are valid we’ll create “ClaimsIdentity” class and
pass the authentication type to it, in our case “bearer token”, then
we’ll add two claims (“sub”,”role”) and those will be included in the
signed token. You can add different claims here but the token size
will increase for sure.
This is why you do not need to store the token anywhere,the token is self contained and everything is stored inside it in an encrypted form. Don't forget that before you add a claim containing the username you have already validated the username and password, so you can guarantee that the token is created correctly for a valid user / password combination. Of course you do not want to store the password inside the token, the whole point of tokens is to avoid doing that. Passing passwords to an API all the time does increase the risk of them being stolen, tokens are much better for this.
Finally, the tokens expire after a time you control, usually they are short lived so even if someone does get their hands on one they will not last long.
If you take care of how you pass the tokens, meaning in the Authorisation Header over an https call then you are as protected as you can be and the headers will be encrypted. The point here is to never issue calls like this over basic http.
The author of the article you referenced is a well respected authority in this particular area and currently a Microsoft MVP and you are basically in good hands. Keep reading his articles, but pay attention to the details.
----------- Clarification related to JWT format --------------
yes the JWT token will contain information related to its issue date and expiry date as well. I have an article of my own on this : https://eidand.com/2015/03/28/authorization-system-with-owin-web-api-json-web-tokens/
Look at the calls which create the token and look at the information returned in the screenshots.
In my example the token contains the actual encrypted token, the token type, seconds it expires in, the audience which is the ClientID, when it was issued and when it expires.
This is just an example of a token, yours will look probably a bit differently but you get the idea I hope. Use Postman to see what's coming back in the token
There are a number of concepts to be understood when it comes to OAuth2, it does require a bit of research and practice.
In short, you request a token with A Basic Authorisation Header, you get the token back and it's telling you what type it is, in my case it's Bearer so that's my next Authorisation Header for any call to a protected resource.
My suggestion is to start small, one step at a time, use Postman to build your calls and understand what's going on. Once you have that knowledge it's much easier to progress. Took me about 6 weeks to wrap my head around all concepts and get something working first time around, but now it takes a couple hours at most. Good luck

The application does not need to store the access token server side, it will only read the user from the token which is passed along.
When the request hits the authentication server, which is attach to the Owin pipeline in the ConfigureOAuth() method,
the HTTP header token is decrypted and the user data from the token is sat to the current user of the context.

This is one of the things that bugged me for a long time
I'm not sure I understand why did you give an example for 2 applications, but the token mechanism is actually simple, but it's kinda black boxed when you use owin and identity
the token is not stored anywhere on the server or the database, authenticating the user on login is done using your logic or usually again black boxed in identity, this involves validating a secured password etc
after this the token is generated (usually using identity) or if you did it manually this will involve securing the token with whatever info you want to store in it
when the user sends a request next time he should pass the token and you will need to decrypt it and validate what's necessary (like expiration time for example), all of this is done behind the scene usually
just a fun note: even if you changed the DB completely the token will still be valid with the user id that doesn't even exist in your new DB! but of course identity automatically invalidates this token when it compares with the securityStamp

Google Contacts API with Service Account issue

So, I've basically got this working, except for one issue. I've got a google service account set up so it can access our domain contacts. And it can batch query them perfectly!
But if I call cr.Retrieve("some-contact-url-here"), it throws an error griping about not having a Refresh token. I'm using a service account though, so I don't get a refresh token when I authenticate.
And I can't seem to find any good answer as to how I'm supposed to get a refresh token for a service account. There's one or two stackoverflow posts which actively mention getting a refresh token with a service account....but what they linked to has since been redirected. Anything else I've found to do with refresh tokens has basically been about authenticating manually and storing the token. Because I need to use a Service Account, that is not a possibility.

A service account's credentials, which you obtain from the Google Developers Console, include a generated email address that is unique, a client ID, and at least one public/private key pair. You use the client ID and one private key to create a signed JWT and construct an access-token request in the appropriate format. Your application then sends the token request to the Google OAuth 2.0 Authorization Server, which returns an access token. The application uses the token to access a Google API. When the token expires, the application repeats the process.
Check this page for more information.

Ok, based on several hours of bashing my head violently against the API, it looks like there's basically no way to get a refresh token when you're authenticating as a Service Account. Expected behavior, really.
Anyway, to get around the issue, you can load all of the contacts into memory,
feed.AutoPaging = true;
foreach (var c in feed.Entries)
{
contactList.Add(c);
}
And you can update|delete|etc then. Grossly inefficient though. Especially if your contact list gets rather big.

Automating login to our own OAuth application

We have some web services with OAuth on them.
I am required to run some tests against them, preferably in an automated environment without using a browser.
The problem is logging in.
Without using a browser, and with using DotNetOpenAuth and setting the HttpContext.Current manually, I seem able to do everything and get a request token and a verifier (I use a test username and password).
I believe the next stage is to get an authorising token. Unfortunatly, no matter how I construct the request, I cannot get it to work.
At the moment, using a WebConsumer (DotNetOpenAuth library) and calling consumer.ProcessUserAuthorization() results in an error:
DotNetOpenAuth.OAuth.Messages.AuthorizedTokenRequest message: oauth_verifier
Probably the whole approach is wrong, so any help/advice would be useful.
Thanks.

I would recommend you skip the entire OAuth handshake and authorization step by having a test access token and access token secret that your web service's token manager always includes. Then wiring your test to also have that token pair included in its token manager, and always using that access token when authorizing your outbound calls.

In the end, it was a problem with cookies not being stored properly.
I was losing cookies between the login page (where the user types their username and password), and the authorise page (where the user says it is okay to share details with the third party). The second page was doing an extra check to see if the user was who they say they were (reading a cookie value that the login page was meant to have written).
It was not really an OAuth issue, just something I did not understand in the Authorising page (which has since been removed anyway - c'est la vie).
I then had issues with the domains of the cookies (when the domain starts with a ‘.’). This post helped me:
CookieContainer bug?
I ended up copying cookies from one domain to another.