Oauth2 not really working on next

(Nir) #1


I’ve been trying to get oauth2 to work on my stoplight instance and it fails no matter what I try - let’s start with client credentials :

with client credentials I am required to supply an audience parameter to auth0 (see: link i can’t add because your system won’t let me post more than 1 link) - since I can’t add parameters to the request it fails.

REQUEST: please allow to add arbitrary parameters to the token request.

With auth code grant it has also been failing- most lately because of this error:
next-api.stoplight.io/oauth_token_capture:1 Failed to load resource: the server responded with a status of 400 ()

callback url is set to what my previous error message said I should set it to: https://next.stoplight.io/oauth/callback/success


(Taylor Barnett) #2

Hi! I’m going to pull in some of the engineering team on this. The one question I have right now is, how is auth0 playing into this? is there some more background info you could share?

(Nicholas Cassera) #3

Hey @nirsoffer ! Looking into your issue, when using authorization code flow, can you verify that you are using the correct client_secret and well as correct login credentials once the auth0 login screen pops up? If either of those things are incorrect it will cause our api server to return with a status code 400.

I am unfortunately not able replicate this issue using the client credentials flow with an auth0 application I set up :frowning:, but I will dig a litter deeper to see if I can get the same error . Could you try removing or adding (which ever is currently applicable) a default audience in the API Authorization Settings, and see if that helps? The default audience field will only accept valid audiences, and those can be found in the auth0’s dashboard api section.

Now for the original request of adding arbitrary parameters to the token request. A very good suggestion, and I will talk with the team to see if we can squeeze it in with our next release at the end of the month!

(Nir) #4

hi @casserni -

I am indeed passing the correct client_secret and id (as far as I know) - and now all of a sudden it started working - today. not sure what the heck happened. Did anything change on your end? because I tried like 50 times last week :smiley:

As for the audience parameter (and arbitrary parameters) :
here’s the missing link from before: https://auth0.com/docs/api-auth/tutorials/client-credentials

The short version is I am implementing an OIDC application - for auth0 that means that the audience parameter needs to be passed to the token endpoint for a client credentials flow - or else it will fail or return a non JWT token (an opaque one) - so it would help be able to define some arbitrary parameters.

(Nir) #5

Also - another silly question - is it possible to hardcode the secret and the id inside next - that would be specifically for sandbox access? right now i have a dedicated application just for the stoplight use case (with a defined callback url) . Also2 - it seems that the box in the documentation implements the auth code grant : the path in the swagger says that the endpoint supports both - is it possible to force a client credentials instead of auth code?

(Nicholas Cassera) #6

@nirsoffer glad to hear that at least auth code is working for you now! As for adding additional parameters to the token request this will be added shortly, but until then I am not sure of a solution. I have created a github issue that you can follow to track the progress/status, linked below

(Nicholas Cassera) #7

Now for hardcoding the client_secret and client_id inside of next. It sort of situational right now but we are in the works of creating a better solution. If you are trying to get an oauth token in an oas file, the answer is no. But we do plan to support allowing you to store them them in you environment and then call them with something like $$.env.client_id.

If you are trying to get an oauth token in a .hub file with the try it out section, you CAN hard code them directly into the code view nested under config like

"config": {
  "http": {
    "oauth2": {
      "credentials": {
        "client_id": "insert client_id here"
        "client_secret": "insert client_secret here",

for more information on that see https://docs.stoplight.io/documentation/authorizations/oauth-hubs

I would like to note that if you add flow to the credentials this will only be applied to http request maker blocks that are NOT automatically generated from connecting/referencing an oas file.

(Nicholas Cassera) #8

Lastly, the issue with documentation implementing only one oauth flow when an endpoint supports multiple. What it appears is happening is that whatever security definition is listed last for an endpoint is the one that is getting show in documentation. So endpoint

  "/endpoint": {
    "get": {
      "operationId": "id",
      "security": [{ "clientCredentials": [] }, { "authorizationCode": [] }]

will display the authorizationCode popup when getting an access token. If you want to force one over the other, list the one you want last. So just swap clientCredentials and authorizationCode. This is another good point though and we should allow the user to select which auth flow they would like to use if the endpoint supports multiple. I went ahead and made an issue for this as well.