0

I am adding application specific claims in my Web Application OnValidateIdentity to Identity Sever's access token claims. I am grabbing the application specific claims for the logged in user querying the Database for every API call. Should I make the application specific claims to be injected in the token in Identity Server (to reduce the DB calls)?

Sabby62
  • 1,707
  • 3
  • 24
  • 37

1 Answers1

1

Identity Server Token should only contain claims about the user. It should be ok to query the application specific claims when the token received. You can introduce a caching layer to reduce DB calls if that is a concern.

But if you have really valid reason these rules can be broken and add application-specific claims at identity server. (e.g: settings shared by multiple apps).

rawel
  • 2,923
  • 21
  • 33
  • Best practice is to add application specific data in claims via reference token and not via identity token, this way you can use introspection endpoint to introspect the reference token and at the api level to read that claim value. You can also add a caching logic for introspection endpoint. This will allow you to cache the introspection results for specified duration. – Himanshu Bhankar Jun 20 '17 at 11:47
  • Good point. But using a reference token introduces similar overhead(network call) to using an application DB call. A valid use case for reference token is when your access token getting bigger regardless of having user specific claims or application specific claims. – rawel Jun 21 '17 at 00:13
  • What should I use to minimize DB processing? I am using SQL Sever 2014. Should I use 2nd level Nhibernate cache or Redis Cache? – Sabby62 Jun 21 '17 at 09:19
  • Sorry, I don't have much expertise on caching. You may raise a different question if you are taking that path. – rawel Jun 21 '17 at 10:05
  • Correcting my own comment above, Token getting bigger is not a valid use case for reference tokens. Please refer https://leastprivilege.com/2015/11/25/reference-tokens-and-introspection/ for use cases. But network overhead is the thing you need to concern. – rawel Jun 22 '17 at 03:37
  • @Sabby62 if are looking for caching, simplest you can go ahead with memcached, there is a pretty neat NuGet package https://www.nuget.org/packages/EnyimMemcached/ it is a NoSQL document store for application caching. Please note Memcache does not provide replication mechanisms by default. If you interested in replication then you may consider redis. – Himanshu Bhankar Jun 22 '17 at 10:32