1 Reply Latest reply on Dec 14, 2015 4:45 AM by NikhilKumar

    Do I need OAuth for my app?

    ralphcook

      I have an application that generates a PDF that the user needs our customer to sign. I have exercised Adobe's demo code to send the document to Adobe and an email to the user, so he can sign it and then the demo code can get status on the doc and see that it has been signed. I'm sure it could obtain the document as well, though I haven't done that yet.

       

      I'm using the Soap interface, v22, and an API key. It is my understanding that this is a key provided for apps that do not support OAuth2.

       

      Is there an advantage in implementing the OAuth2 logic in my application? Is it more secure, with timeouts or for other reasons?

       

      From what I've read, OAuth2 is meant for cases where the application needs the user to authorize access to something for the application -- Does that fit this situation? It seems to me the application is accessing the document at Adobe that the application put there; the user doesn't really need to grant permission to do that. Is the Adobe API supporting OAuth2 for some other purpose, or is it useful or necessary in my situation somehow?

       

      If I should use OAuth2, how does it fit into the Soap message logic?  I don't see a mention of it in the WSDL, does that mean there isn't a soap message to for sending the application ID and client secret and getting back the authorization code?

        • 1. Re: Do I need OAuth for my app?
          NikhilKumar Level 1

          Hi,

           

          You should definitely use OAuth as there are multiple advantages of using OAuth tokens over API key. Few advantages of OAuth over API key are: -

           

          1. API Key are permanent and can not be revoked where as OAuth tokens can be revoked
          2. Access token provides fine level control in terms of authorizing various operations like agreement write, user write etc. where as API key simply authorizes for all the scopes. It does not provide any granularity in terms of authorization.
          3. You can have different OAuth token for different application whereas API key remains same across all the API calls. Different application identifier provides better analytics and easier troubleshooting if something goes wrong.

           

          Because of above security concerns, EchoSign has stopped issuing new API keys. It might be the the case that API key is enabled for your account but end user of your application may not be able to get an API key issued and may not be able to use your application.

           

          Your use case fits well in the OAuth workflow. You should do an OAuth and only ask for authorizations needed in your workflow. From your workflow, it looks that you only need agreement_read and agreement_send or agreement_write and may be user_login scope depending on how you are sending the agreement.

           

          OAuth documentation is available at https://secure.na1.echosign.com/public/static/oauthDoc.jsp which explains in details various OAuth scopes, how access token and refresh token works along with their timeout mechanism. There is also a demo code at the end.

           

          Moving to OAuth tokens in SOAP API is very easy, all you need to do is use access token that you will get from OAuth workflow in place of API key string. Every thing else remains unchanged.

           

          On a side note, you seem to be using SOAP APIs for your requirements. EchoSign also provided REST APIs documentation for which is available at https://corporate.na1.echosign.com/redirect/latestRestApiMethods

          REST APIs provides a clear OAuth support with exact scope requirements for various API endpoints. Also REST API documentation provides an interactive documentation from where you can directly invoke APIs and play with them. On REST API documentation, with every API there is an OAUTH-ACCESS-TOKEN button which will help you generate OAuth token and use API with that token.


          Thanks,

          Nikhil