I'm working on a project that has an MVC Web API that lives on a different server from an MVC5 application that needs to consume the API. Because the user information is stored in the same database as the rest of the information that the API is responsbile for, I decided to keep 100% of the data layer in the Web API.
In the near future, I'll write a post about how I accomplished managing the bearer token and user identity, but for now, I just want to give others a word of warning:
Do not use claims to store the bearer token. It will grow out of control, and you will be plagued with "Request too long" errors.
Because the bearer token is just another way of describing the user's identity, any claims associated with the user (including custom claims) will be included in that token. So now, we have a token being generated that describes the typical information about a user, plus another token. This makes it grow to the point where I was getting tokens over 16,000 characters in length. Typically, tokens only grow up to about 300 characters.
When sending a request to an API method that requires authentication, you need to pass this token as a header, and you can get a response. If the token is 16,000 characters long, the server will just reject the request with a "Header too long" response message. Furthermore, because the MVC site is using cookie authentication, the information stored in the cookies grew to an unmanagable size as well, and I couldn't even get back to the log in page.
If you must do it like this, make sure your API removes the claims in the identity model, and your consuming application re-adds them (which defeats the purpose of only having one application as a data layer).
I'm hoping to have a better way of managing this later, and will post another entry then!