Any usage documentation for the OAuth API endpoints?

I am not finding any decent documentation on how to use the following OAuth endpoints and in what order:

  • GET https://app.netlify.com/authorize (response_type = code | ticket??)
  • POST /oauth/tickets
  • GET /oauth/tickets/{ticket_id}
  • POST /oauth/tickets/{ticket_id}/exchange

Using the response_type=token is pretty straight forward. However, it’s unclear to me how to utilize response_type of value code or ticket

I don’t see anything about ‘ticket’ in the OAuth specification: https://tools.ietf.org/html/rfc6749

Thanks for your time.

hi, just checking you saw this already?

Thanks, @perry, for the response. I am familiar with the page you mentioned. It’s still unclear to me how, and in what order, to utilize the endpoints properly in the afore mentioned contexts. Hopefully I am missing something simple.

Additionally, the interest is to exercise the endpoints without using the js or go client libraries. Looking for documentation or code samples that utilize the afore mentioned endpoints in the correct order.

What is a ticket anyway?? :wink:

Update: I was able to get the ticket authorization steps to work however the Redirect URI is not used for some reason. After authorization, the process stops at Netlify. The Redirect URI is used with the implicit OAuth authorization (https://tools.ietf.org/html/rfc6749#page-8) but it’s not used with the ticket authorization. Am I missing something? (See screenshot)

The goal that I am trying to achieve is the ability to orchestrate authorization via OAuth (Netlify’s OAuth Application) in our browser/server environment and not expose the access token to client side code. It appears that Netlify’s (non-standard?) ticket approach is the way to go however we are missing the Redirect callback feature. Is there a way to get notified if the user has granted authorization in this ticket authorization scenario?

Any help would be appreciated. Thanks for your time.

Hello. Still waiting for a response to this inquiry. Any help is appreciated. Thank you for your time.

Hey @tempest-mind,
We’re not ignoring you- we need to bring your OAuth questions (this one, Hosting the authorization page in an IFRAME?, and Parameterized redirect_uri value?) to our backend team and hopefully get some answers. We’ll respond here when we know more!

Thanks, @jen. After a little more research; the following library: netlify/js-client provides a fair amount of clues for using the response type of ticket. I believe the wisdom behind the ticket response type is that it does not require a redirect URI callback? Feel free to correct my assumption. That said, it does appear that we need to poll to see if the user authorized the OAuth app (since there is no callback URI with the ticket system). At the moment, this technique seems a little challenging/contrived in a browser setting - but manageable.

For what its worth, it appears that the reference to openBrowser in the netlify/js-client README file is intended for the user to implement. It’s not defined anywhere so it was slightly confusing.

Lastly, I have yet to figure out if Netlify fully supports the response type of code in accordance to the OAuth2 spec. I can get a code response however I am unable to exchange the code for an access token. I have yet to find a ‘token endpoint’.

.

Hey @tempest-mind,
Thanks for your patience! I met with one of our backend engineers today and got some clarity on several of your questions.

For your question about programmatically creating OAuth apps with the API, we’d recommend checking out this post on reverse engineering our UI in cases where there are no OpenAPI docs: [Support Guide] Understanding and using Netlify's API If you watch the call we make in the UI when creating an OAuth app, you’ll see that it’s a POST with a JSON body to api.netlify.com/api/v1/oauth/applications. The caveat with calls that aren’t documented is that the routes could change, but that route is an OAuth standard and not Netlify-specific… so less likely to change than some others!

These are some of the other routes we use: https://doorkeeper.gitbook.io/guides/ruby-on-rails/routes

You asked about ticket. The ticket is a special kind of abstraction within the Netlify CLI. The reason we use it there, and the reason we need to poll to see if the user has authorized, is because the CLI doesn’t have a direct way to communicate with the browser. But this is not the typical way to do OAuth. If your authorization is all happening within the context of a browser, you should do something more like what’s described in this blog post:

The code is linked in there but in case you just wanna dive in:

Please let us know if that helps or if you have other questions about this!