0

I am using thinktecture identity server v3. I created web application and web api service. when I am accessing the web application, I got the access token from identity server. I used this token as bearer token to communicate with web api. Everything works fine.

But I noticed that at api server, for every request with access token, it automatically calls the identity server. If the idenity server is up, then it served otherwise it gives unauthorize error.

  1. What is the purpose of this call?
  2. What data it carries with the call?
  3. If it is for validating the authority, it will more burden to the identity server.
  4. Is it possible to skip this call?
Vamsy
  • 144
  • 4
  • 16
  • Identity server has two types of tokens, Jwt and reference token. You are probably generating reference token, which is opaque to the client. It is just a string and has not information for client to validate. If you are generating jwt token, api can validate on its own by validating issuer, audience and validating signature. – Shetty May 03 '16 at 13:31

1 Answers1

0

You cannot avoid this:

  • when a user authenticates with the identity server, it creates a token which is given to the client to indetify itself. This token is created on the fly by the identity server, which remembers it
  • the client presents this token to your Web API server, which knows nothign about it, but knows who can validate it. So your Web API server communicates with the identity server so that it can get the identity back from the identity server

That's the reason why it works this way.

If you wanted to avoid this behavior you could map the identity from the external identity server to an identity controlled by your own web API server, and use an authentication method under your control to avoid querying the token from the external identity server. However, if you're using an identity server is precisely becasue you don't want to implement it by yourself, so this option makes no sense. This option is used when you want to map users from popular external identiy servers (like Google or Facebook) to users under your control.

JotaBe
  • 38,030
  • 8
  • 98
  • 117
  • For every request, api go and validate the token. This is more burden on the identity server. My point is, api service should validate itself without going to identity server. Suppose there is a building which contains 10 companies. Someone came meet the MD of company X. First he stopped at gate and security personal asked details about him and give some card(token). he came from gate and went into company X show the token. Then he verified the card and accept it. But in our point of you, company X again go to security personal and verify the token. Is it correct way? – Vamsy May 21 '15 at 09:37
  • The security personnel at the gate are form an external company, S, and give the visitor a token of company S. At your're company way, you don't know if the token from S is valid or not, so you contact S and they confirm that the token is valid. From this point on you can do 2 things. 1) you can keep doing it, whenever your users presents the token from S, check if it's valid with S company 2) give him your own token (any authentication method under X control), so that when the person comes back you recoginize him without contacting S again – JotaBe May 21 '15 at 09:44
  • My question is we already trusted the external company S as idenity provider why we should go back and validate it. – Vamsy May 21 '15 at 09:50
  • It's difficult to give you an answer without seeing your code and configuration. Have you got the public key of the identity provider in your Web API to validate the token, without contacting the Id. provider again? it looks like you don't have it or are not using it. – JotaBe May 21 '15 at 16:56
  • Why not add caching here? You go ahead and the do the validation with the issuer only the first time and cache the response for subsequent request. Moreover, you can control the cache expiry to ensure this check is fired again after a set interval. – Prafulla Nov 27 '15 at 09:21