0

I have two different REST API’s say Authentication API & Business API hosted in Windows azure.

Authentication API is responsible for authenticating user using WsFederation or OpenID or custom authentication

Business API is responsible for executing business logic. Only legitimate user should be able to access this API.

Client will contact first Authentication API and will acquire the token and then it will pass that token to Business API.

Since client can send any token to business API. Business has to validate the token. It simply cannot trust on the token. Since token Is generated by Authentication API, how business API will validate the token.

What is a standard way to validate the token in such scenario where Authentication API and Business API are hosted separately?

parag
  • 2,483
  • 3
  • 20
  • 34
  • Looks like you can use [OAuth 2.0 Bearer token](https://stackoverflow.com/questions/25838183/what-is-the-oauth-2-0-bearer-token-exactly) – Jayendran Nov 03 '18 at 15:03

1 Answers1

0

Good References

  • Principles of Token Validation (Vittorio's blog) - Awesome article, most of the information is generic so applies with or without Azure AD, and it's coming from a very knowledgeable author of course

  • Manually validating a JWT access token in a web API - This one is specific to validating an Azure AD issued token. Has complete code implementation too. You don't need to do exactly this, because your validation will depend on token format/claims that you use but may provide a helpful reference.


You can look at how token validation is recommended for applications secured by Azure Active Directory as a case study (and may be some other systems as well), then decide what works best for your case.

Brief explanation on how Azure AD example is relevant.. as validating received token is required just like in your case

When you develop any web API (or web app) secured by Azure Active Directory and use bearer token based authentication, the way things flow is very similar to what you explain above with your 2 APIs (just for understanding purpose, your authentication API is doing what Azure AD token endpoints would do.. i.e. provide a valid token).

To access the secure web API, calling application/client first interacts with Azure AD endpoints to get a relevant token for required resource, then it sends a request for actual resource along with the token in Authorization header to the web API. Now, the first thing web API does is to validate this token and only if everything is correct continue with execution to eventually return a response. I hope this matches at a high level with your flow.

What to validate?

1. Token Signature

The key used to sign the issued token is uniquely associated to the issuing authority, so nobody else can issue a token with your Authority's signature.

a. This helps to check that the token was in fact issued by Azure AD (or in your case your trusted STS, using the Authentication API you mention).

b. This also makes sure that since the token was issued and till it reached your web API, no body has tampered with it. If any attempt is made to change any information in the token, the signature will break.

2. Token Claims

This will depend on what claims/information you send as part of the token (for example, if same Authentication API issues tokens for multiple different APIs, then something like audience and issuer might make sense for you as well. Token validity time period using something like nbf and exp below are also pretty generic)

Taking Azure AD issued tokens as example here are the important ones that should be validated:

  • audience claim (aud), to verify that the token was intended to be given to your application
  • not before (nbf) and expiration time (exp) claims, to verify that the token has been received within it's validity period
  • issuer claim (iss), to verify that that token was in fact issued by the said authority. Notice this is a second way, apart from signature for the same purpose and generally both signature and issuer check are used together. (See Vittorio's blog)
  • nonce, as a token replay attack mitigation
  • tenant claim (tid), to verify the tenant. This is useful in case of multi-tenant applications.

Sample JWT Token from Azure AD Actual Value: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1N... (a long encoded string continues) Decoded Value (you can check this easily using a website like https://jwt.ms or https://jwt.io):

{
  "aud": "https://service.contoso.com/",
  "iss": "https://sts.windows.net/7fe81447-da57-4385-becb-6de57f21477e/",
  "iat": 1388440863,
  "nbf": 1388440863,
  "exp": 1388444763,
  "ver": "1.0",
  "tid": "7fe81447-da57-4385-becb-6de57f21477e",
  "oid": "68389ae2-62fa-4b18-91fe-53dd109d74f5",
  "upn": "frankm@contoso.com",
  "unique_name": "frankm@contoso.com",
  "sub": "deNqIj9IOE9PWJWbHsftXt2EabPVl0Cj8QAmefRLV98",
  "family_name": "Miller",
  "given_name": "Frank",
  "appid": "2d4d11a2-f814-46a7-890a-274a72a7309e",
  "appidacr": "0",
  "scp": "user_impersonation",
  "acr": "1"
}

How to do token validation?

Make use of standard libraries as much as possible. See the code implementation sample Manually validating a JWT access token in a web API. This one makes use of JwtSecurityTokenHandler.ValidateToken Method (JwtSecurityToken). Your case will depend on your token format/implementation etc.

Rohit Saigal
  • 9,317
  • 2
  • 20
  • 32