0

We have a SPA that is protected with Azure AD. This seems to work fine, and users can authenticate ok.

We also have a spring boot rest service, that is also secured by Azure AD. When we try to do an GET from e.g. chrome, we get redirected to Azure for authentication, and then routed back to the rest service where we get the result.

But, when we try to call this rest service from SPA client, it does not work. Our client is running on http://localhost:5010/ and when we try to access the rest service, after the client itself successfully has authenticated against Azure, we just get a redirect to http://localhost:5010/login

This tells me that the rest service are not able to verify the clients authenication, but I don't understand why.

We use adal-angular4 in our SPA and adal4j in our spring boot server.

How can I make the rest service accept tokens from SPA client, without trying to re-authenticate rest service?

Ganesh Manickam
  • 2,113
  • 3
  • 20
  • 28
Tore Tjøtta
  • 1
  • 1
  • well, to begin with, is SPA client sending the auth tokens? have you confirmed it? – eis Dec 07 '17 at 12:50
  • yes, it is. The headers in request from SPA that fails looks like this: Host: localhost:5010 Connection: keep-alive Accept: application/json, text/plain, */* X-XSRF-TOKEN: 1c35cf04-25a1-4c59-8429-6e48b8484ef3 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Referer: http://localhost:5010/vesselActivity Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.9,nb;q=0.8 Cookie: XSRF-TOKEN=1c35cf04-25a1-4c59-8429-6e48b8484ef3 – Tore Tjøtta Dec 07 '17 at 13:09
  • XSRF token is not the same thing as authentication token... – eis Dec 07 '17 at 13:11
  • The main difference from a request that works is that then we have this: Cookie: JSESSIONID=E515EE0C71F8CAF42DF2F40925490998; XSRF-TOKEN=2a88b3bf-024a-4516-99cb-2fecec4b6242 Is it the JSESSIONID that contains the token then?? – Tore Tjøtta Dec 07 '17 at 13:20
  • no `Authorization` header? – eis Dec 07 '17 at 14:11
  • Actual, after you pointed out that the authorization header was missing, I found an error in our SPA implementation. Now we get the header correct, but are facing other issues, but that has to do with configuring azure correctly. So, thanks for pointing me in correct direction – Tore Tjøtta Dec 08 '17 at 13:36
  • ok, good it was of help. added as an answer. – eis Dec 08 '17 at 13:58
  • @ToreTjøtta, Can you please tell how you fixed this in SPA?. I have the exact same problem. – krisho May 13 '20 at 06:02

1 Answers1

0

According to the comment, you got these as headers:

Host: localhost:5010
Connection: keep-alive
Accept: application/json, text/plain, /
X-XSRF-TOKEN: 1c35cf04-25a1-4c59-8429-6e48b8484ef3
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
Referer: localhost:5010/vesselActivity
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,nb;q=0.8
Cookie: XSRF-TOKEN=1c35cf04-25a1-4c59-8429-6e48b8484ef3

Only Cookie is XSRF cookie, so it seems you're lacking authorization headers in your client app.

eis
  • 51,991
  • 13
  • 150
  • 199