We’ve developed some resources to help you work effectively from home during COVID-19 Click to learn more

REST API authorization

Hi, a prospect for our Online offering has a question about the REST API's we would like to reply. Could you please look at the following question:

In the documentaiton (https://community.superoffice.com/en/content/content/general/introduction-to-superoffice-apis/ and https://community.superoffice.com/documentation/sdk/SO.NetServer.Web.Services/html/Reference-WebAPI-Authentication-Online.htm) we can only find oAuth to authorize using REST API (only this variant where a user gives permission).

For the system we want to create, requests will come in using a form and need to be registered within SuperOffice. Therefor oAuth does not fit (as described in the documentation), so the question is if there is a way to authorize this from a server application (shared secret, api key, ...)?

RE: REST API authorization

You can totally use OAuth 2 - you need to get a refresh token via the Code Flow, and then use that refresh token to get a new access token you can use to access the system on behalf of the authorizing user.

So as part of your setup you need to provide the authorizing user a chance to log in to SuperOffice and authorize the app.

This is how the Zapier integration works.

Take a look at https://community.superoffice.com/en/developer/apps-partners/develop/security-and-authentication/online-superoffice-online-open-id-connect/#Authoirzation_Code_Flow_110

and https://community.superoffice.com/documentation/sdk/SO.NetServer.Web.Services/html/Reference-WebAPI-Authentication-Online.htm

Von: Christian Mogensen 5. Sep 2019

RE: REST API authorization

Thanks a lot! Ok, so this should not be a problem for them. Good to have this information and I will share it and see if this answers their question.

Von: Maarten Reuser 5. Sep 2019

RE: REST API authorization

One additional question on this topic. The Code Flow only works if the Superoffice user interacts with the application. In our case, the Superoffice user does not interact with the web application, only end-users do.

Zapier works differently, here a Superoffice user grants acces to Zapier. Most oAuth 2 secured services also have a 
Client Credentials flow which allows access (obtaining an access key) without the use of a browser. Does Superoffice have this capability as well?

Von: Maarten Reuser 10. Sep 2019

RE: REST API authorization

Hi Martin,

Yes, that's correct, but only once. Imagine it as if consultant or customer administrator has to perform an installation one time. After that first time, they will get the long-lived refresh token, which then should be stored. Then, in all subsequent non-interactive requests, use the refresh token to obtain an access token for further authenticated access. Repeat the process each time authenticated access is required.

Hope this helps!

Von: Tony Yates 10. Sep 2019

RE: REST API authorization

Thanks Tony! I hope this will supply the answer they need.

Von: Maarten Reuser 10. Sep 2019

RE: REST API authorization

In my previous request I asked the following question: "Most oAuth 2 secured services also have a Client Credentials flow which allows access (obtaining an access key) without the use of a browser. Does Superoffice have this capability as well?"

Should I assume from you reply that the answer is "No, Superoffice does not have this capability"?

Von: Maarten Reuser 12. Sep 2019

RE: REST API authorization

We dont have this capability at this time.

Von: Christian Mogensen 12. Sep 2019

RE: REST API authorization

The customer would like to built another flow using (Client Credentials). Are there any possibilities in this area? Are we working on such a possibility for future releases?

See needed option below:

The Client Credentials grant is used when applications request an access token to access their own resources, not on behalf of a user.

Request Parameters

grant_type (required)

The grant_type parameter must be set to client_credentials.

scope (optional)

Your service can support different scopes for the client credentials grant. In practice, not many services actually support this.

Client Authentication (required)

The client needs to authenticate themselves for this request. Typically the service will allow either additional request parameters client_id and client_secret, or accept the client ID and secret in the HTTP Basic auth header.

Example

The following is an example authorization code grant the service would receive.

POST /token HTTP/1.1
Host: authorization-server.com
 
grant_type=client_credentials
&client_id=xxxxxxxxxx
&client_secret=xxxxxxxxxx

See Access Token Response for details on the parameters to return when generating an access token or responding to errors.

Von: Maarten Reuser 18. Sep 2019

RE: REST API authorization

Hi Maarten,

We are aware of the need for Client Credentials support. We do not support it today, but it is something we do have on our roadmap/radar.

Best regards.

Von: Tony Yates 20. Sep 2019

RE: REST API authorization

You are right, thank you Tony!

Von: Maarten Reuser 23. Sep 2019