Code Examples for Oauth 2.0?

Hi @John Schilling​ ,

For the 3-legged OAuth / authorization code grant (https://tools.ietf.org/html/rfc6749#section-4.1), we have an example at https://github.com/Brightspace/oauth2.0-client-example (node.js) that calls whoami after successfully obtaining an access token.

Mark

@John Schilling​ 

Have you had success remaking the node.js OAuth example in PHP (or making any PHP OAuth connection to Brightspace)?

(I haven't tried yet, but always love getting a head start)

Sorry for the late reply @Hugh Gleaves​ (was on vacation).

Could you provide more details around "That back end server uses a process that is manual to get the access tokens initially"?

Is the back-end server using an access token directly? Those typically expire within an hour, and would require manual setup each time.

Alternatively, is the back-end server managing refresh tokens to obtain an access token (https://community.brightspace.com/s/article/ka1610000000pYqAAI/How-to-obtain-an-OAuth-2-0-Refresh-Token)? That is currently our recommended way of keeping a back-end server going indefinitely, as that workflow only requires a one-time manual step.

Refresh tokens do expire after 30 days, but as long as you trade it in for a new refresh token within that time, you get a new refresh token that expires 30 days from the time it was traded in. As long as the back-end service runs once every 30 days, it should be able to run indefinitely.

If you are manually getting access tokens, I would recommend switching to the refresh token workflow. If you are using the refresh token workflow, I would be interested in hearing more about what the code is doing to understand if there may be an unknown limitation to the refresh token workflow.

There is also a PIE item (https://community.desire2learn.com/d2l/lp/navbars/1796/customlinks/external/15394) for adding client credentials grant support. I encourage you to upvote the item and post your use case there if the refresh token workflow doesn't meet your needs.

Hope that helps, and looking forward to hearing from you!

Mark

@Mark Tse​ - Hi, OK I've extracted the core code we're using currently to authenticate our back end apps with Valence. I've simplified this to a minimum and run the code so it gets real results to a particular call.

    static void Main(string[] args)

    {

      var factory = new D2LAppContextFactory();

      var appContext = factory.Create(appid, appkey);

      var usrContext = appContext.CreateUserContext(userid, userkey, new HostSpec("https", host, 443));

      var auth = new ValenceAuthenticator(usrContext);

      var client = new RestClient("https://" + host);

      var request = new RestRequest("/d2l/api/le/1.12/9531/grades/values/11868/", Method.GET);

      auth.Authenticate(client, request);

      var response = client.Execute(request);

    }

I've not include the five strings for hots, userid, userkey, appid and appkey for obvious reasons.

Now my understanding is this was our best option for having general purpose code interact with Valence and the expiring I referred to earlier is that one or more of these strings does seems to eventually lose validity and we must manually regenerate them.

This has happened several times and has impacted our production systems, from what I gather we must use the API test tool web page to generate fresh values to restore operation.

We may be doing this all wrong but I was told that a phone call last year with a D2L engineer advised us to follow this approach.

@Mark Tse​  the link in your original post is broken. Do you have an update / later version of the code example?