Invalid signup in Spring Boot Quickstart

[adammtlx]

I’m following this Quickstart guide: https://auth0.com/docs/quickstart/webapp/java-spring-security-mvc

I downloaded the sample application, created a new Auth0 application and filled in the auth0.properties file with the required values from my Auth0 application, and added the callback and logout URLs as instructed. The app runs, but upon filling out the signup form I get this error in the signup request:

{"name":"BadRequestError","code":"invalid_signup","description":"Invalid sign up","statusCode":400}

I checked the values being sent in the signup payload and they all conform to the values expected. This is about as “out of the box” as can be expected but it still doesn’t work, and I’m unsure of how to proceed. Any suggestions?

[konrad.sopala]

Hey there!

Thanks for reporting that. In order to handle that most effectively can I ask you to open a GitHub issue in the quickstart repo so that repo maintainers can work with you directly? Once you have the link make sure to share it here with us so we can ping them. Thanks!

[adammtlx]

Will do, thanks for the feedback!

[konrad.sopala]

No worries! Waiting for the link then!

[adammtlx]

Hey Konrad, I went back to rerun the code to get some details when I realized I had accidentally been using the same test user I’d used before while doing something else, which was the cause of the failed signup. However, even using a new user results in an error. The new user gets created successfully, but the synchronous callback to my server-side application fails. On my side, this is the internal exception:

com.auth0.IdentityVerificationException: An error occurred while exchanging the authorization code

This is the only useful information I get on that side, nothing about why the failure occurred. Unfortunately, due to the way Spring sets up its authentication interceptors ahead of time, I’m having trouble following the stack trace, but I set some breakpoints in the Auth0 code and it looks like perhaps either my security config isn’t being set up correctly, or isn’t handling the code correctly. In Auth0’s RequestProcessor a method called getVerifiedTokens is invoked right before the error, which extracts a parameter from the request called “code”, which is set to a value like this: 7nikwMeTUhUUnTvS. Just a hunch, but this seems too short to be a valid authentication code or token.

On the Auth0 side, the logs just show a failed exchange (multiple times):

{
"date": "2020-03-07T12:35:47.823Z",
"type": "feacft",
"description": "Unauthorized",
"connection_id": "",
"client_id": "<my client id>",
"client_name": null,
"ip": "<my IP>",
"user_agent": "okhttp 3.9.1 / Other 0.0.0",
"details": {
  "code": "*************h69",
  "device_id": "v0:2bf2ed90-6370-11ea-8f23-216edf211cd7"
},
"hostname": "myapp.auth0.com",
"user_id": "",
"user_name": "",
"auth0_client": {
  "name": "auth0-java-mvc-common",
  "env": {
    "java": "1.8"
  },
  "version": "1.2.0"
},
"log_id": "90020200307123552210000546592527758043317896755812499554",
"_id": "90020200307123552210000546592527758043317896755812499554",
"isMobile": false
}

I noticed in the log message above that the user information seems to me missing, but I’m not sure if that’s a problem or if that would explain the issue. I’ve triple checked that my domain, clientId and clientSecret are all correct. Everything on my side is straight out of the quickstart I mentioned in my original post, with zero alterations.

Any ideas?

[adammtlx]

I figured out the problem. The single quotes on the client secret were causing the token exchange to fail. Once I removed those, the exchange worked correctly.

As a follow up question to this, I’m trying to redirect to a front-end application running on a different port. The only “evidence” of the successful token exchange that I can find within the browser is the presence of a cookie called “com.auth0.state.” Can I use this cookie from the front-end to make authorized API calls to my back end, or am I going about this the wrong way?

[mathiasconradt]

You should use the received access token you get in the callback to make API calls (not rely on a cookie). That’s what the access token is explicitly for.

The usual way is that you use that you register your API in the Auth0 Dashboard under APIs. Then use the API identifier from there as the audience in the authorization request you make from your Java app.

You can refer to this authorization Quickstart to get an idea.

https://auth0.com/docs/quickstart/backend/java-spring-security/01-authorization

A general description of the Authorization Code Grant flow, which might also be helpful, is here:
https://auth0.com/docs/api-auth/tutorials/authorization-code-grant#2-exchange-the-authorization-code-for-an-access-token

[adammtlx]

not rely on a cookie

Right, I understand this, but there is conflicting info about this in the Auth0 docs. There is documentation that specifically mentions the use of cookies in certain circumstances, such as when you are running your own back end, or when the back end is on the same domain as your SPA, etc.

The reason I ask is because I am trying to authenticate calls for binary data that are made with <img> tags using their src attributes, which cannot attach an authentication token to their headers. I brought this up in another topic (Correct way to make authenticated calls for binary data in image tags - #6 by mathiasconradt), and one suggestion is to load the binary data directly into the src attribute, but this is still not ideal because it requires additional complexity as well as forcing workarounds should the user, for instance, want to link the image (e.g., to another user who is also authorized to view it), among other potential lurking issues. It also appears to preclude the possibility of loading non-image binary data via authenticated requests, such as video and audio.

IMO this seems like an oversight on the part of Auth0. It may be an infrequent use case, but surely the need to authenticate requests for data loaded via HTML elements is something that should have a defined solution and path, rather than resorting to hacky workarounds?

[mathiasconradt]

Ok, now I see what you mean.

There is documentation that specifically mentions the use of cookies in certain circumstances, such as when you are running your own back end, or when the back end is on the same domain as your SPA, etc.

I guess you’re referring to

• Token Storage
• Authenticate Single-Page Apps With Cookies

Yes, if this approach works for you (and given scenario applies), then that’s fine (the approach described in that second link).

(I initially had a stateless frontend in mind, frontend and backend being independent from each other. Just don’t store the JWT in a client-side cookie.)

[adammtlx]

Correct, that is the documentation I am referring to. The problem I’m currently having with that documentation is that I cannot get it to work in my use case (Spring Boot back end, Vue SPA front end). My back end is running on a separate port, therefore not the same exact domain, but it’s not clear to me if this precludes or profoundly complicates the notion of using cookie authentication.

I suppose what I’m looking for is a recommendation on how best to secure binary endpoints that will be requested by HTML elements when using a front end and back end running on separate ports (and potentially separate sub-domains or domains). As mentioned, the workaround of using a Vue directive to make an authenticated request to the back end and then insert the binary data directly into the src attribute of the tag should work, but is hardly ideal. Any other thoughts?