0

I'm writing my first ASP.NET system with Claims Based Authentication (i.e. noob alert). I'm jumping straight into the deep end, with separate authentication and resource services. So my app needs first to authenticate on API "A", and on API "B" I need to build up a claim set to determine whether the user thus authenticated is allowed access to the given resource.

Unfortunately, every tutorial I've found on the web has assumed that the authentication can be done in the same place as the claims are hydrated. In my case, this simply does not work; all that API "A" will tell me is that the user is who he says he is; it's up to API "B" to determine now what claims the user has.

My question is: in API "B" (the resource server), how and where do I receive the authentication token, and work out what claims need to be assigned to this identity? Should the claims be hydrated immediately after login and let the client store the claims? Or should I be working out the claims every time an API endpoint is called?

Shaul Behr
  • 36,951
  • 69
  • 249
  • 387
  • I believe the claims are better positioned on the server. At least things are more difficult to be stolen from there than from a client machine. – Lajos Arpad Jul 19 '15 at 15:45
  • @LajosArpad as I said, I'm a complete noob at this. What's the hook on the server side for creating claims for an authenticated user? – Shaul Behr Jul 19 '15 at 15:48

0 Answers0