x Want to participate? Join the group to interact
New

Please supp the client credentials grant type on your API

More and more customers are wanting coupled integration with Sage 200 / Standard using the API from their e-commerce sites so this is getting to be an urgent requirement for a lot of developers.

This then requires a service to written to get orders into Sage and stock items out etc. (at a very basic level)

Using your API as it stands it does not support the grant_type of "client credentials" when authorising to the https://id.sage.com/authorize endpoint.

This poses a significant challenge for non ui service type programs trying to use your API as it requests a login via a GUI interface and as I have recently found out, the refresh token also expires so you cannot login once then use the refresh token to get a new token (and a new refresh token with a new expiry) to continually use the API without having to login again.

Implementing the client_credentials grant type would allow developers to write server to server programs and login programmatically and thus keep customers from moving away from using the Sage API due to this limitation. 

Thanks

Jim

Jim Booth
  • in reply to Will Selway

    Found the answer here confirming my guess - https://developer-community.sage.com/topic/528-unattended-confidential-client-oauth-integration-to-sage-200-api/#comment-1494
    "You can essentially have a connection to the UKI 200 API unattended using the refresh token to maintain it. During the initial setup, manual login must be provided as part of the oauth process, but after that, the access token can be refreshed indefinitely and without the need for manual intervention. "

  • in reply to Chris Gorringe

    Thank you, I will try.
    For future readers, it looks like the only solution is to go for the authorization_code grant type via redirect URL, get the refresh token and store that for use by a server. Even thought its actually for a user. And if that ever expires get a new one and put that into your server / secrets manager.

    Whenever our accounting manager logs into our CRM, we can get them to do the OAuth sage login flow, and store the access token for use by a sever, and not actually by them.

    That's really a bit of a hack and why OAuth has the client_credentials grant type in the first place to prevent people having to do this, but it is what it is. Really disappointing and behind the times. Will just make the integration so much more brittle as if we have staff turnover exct, our application will need to be changed to make sure we are getting tokens for sage generated for a different user.

    Really not good from an auditing front. If our job goes and updates data in sage, surely the change logs will be against the name of whoever the access token is for, making it look like they did it, and not an automated job.

  • in reply to Will Selway

    Have a word with developer support. We have a number of clients who are very successfully authenitcating server-to-server (web server to Sage API) and there is no UI login required to authenticate from the web server to the Sage server.

  • in reply to Chris Gorringe

    Thank you for your reply. No it does not.

    It looks like it doesn't support 'Confidential Clients', at least in the way you describe it.

    What is the grant type we should be using to do as you say, if it is not 'client_credentials'?

    Please can you link to any documentation for this? While https://gb-kb.sage.com/portal/app/portlets/results/viewsolution.jsp?solutionid=210226173239343 mentions -

    "Web Client: Web based applications that store the Client and Secret keys on a server are classed as Confidential Clients. They are more secure because only the server has access to these keys; they are not distributed to end users."

    The walkthrough on it requires a using to login to sage manually while the access token is being generated, so is no good for automation.

  • The API supports two types of authentication and if you want server to server comms, you need to use type Confidential Clients type as opposed to the Public Clients type. The Confidential Clients type allows you to progromatically authenticate using predefined keys and UI. the Public Clients type is for desktop apps that expect the user to authenticate with a UI.

    Does this answer your problem?

*Community Hub is the new name for Sage City