0

Currently I have this setup:

enter image description here

At login, and in every subsequent request after login, a mobile application that I have built uses Basic Authentication to authenticate the user with a web service that serves the app with information it requests.

On every request the Authorization header is inspected, the password and username are extracted from the header, the password is hashed using a proprietary DLL (so the web service doesn't actually contain the hashing algorithm) and compared to the hashed password associated with the username that is stored in the database.

I have now been asked to include Azure AD SSO in the login options. After reading much about the topic, this looks seems to me like the setup:

enter image description here

I'm curious about a few things:

  1. Is this setup correct, more or less?
  2. Does the app send the Identity Token to the web service? If so, how does the webservice validate that token?
  3. Is it correct that the webservice can match the Azure Identity to the DB user using one of the claims in the Security Token?
  4. Where do Access Token fit in this picture?

Thanks for the help!

(Side Note: I know that Basic Authentication is not the preferred way to go in the first scenario. This was a temporary decision till we developed the token handling code, it only works using HTTPS and this is an internal application - you wouldn't be able to activate the app unless you have a code we give you)

frezq
  • 653
  • 8
  • 18

1 Answers1

1

I have little experience in azure ad but I think we could talk about your case.

First, whatever id token and access token are both jwt token, so to your web service application, you need to use jwt decode library to decrypt the token and get claims it contains. Here we need to know the difference between id token and access token, and I think you'll know that for your web service application, if it's more likely to play the role of an api application, you need to use access token because this token also contains user information. Then you need to add code in your program to decode the token and check if it's a 'valid' token for the request.(Because you've used azure ad to achieve the login part, you don't need to use your custom login part.)

Next, the signing in feature provided by azure ad requires to use account and password in the tenant which azure ad belongs to, the user accounts may look like xx@xx.onmicrosoft.com, it doesn't required to keep sycn with the accounts in your database, so it's difficult and needless for you to compare the user name obtained from the decoded token with those in your database. Because when your web service received the token(id or access token), that means someone has passed the authentication from azure ad. The token contains user information including role, expired time etc. You need to check if the token has expired and if has the correct scope. (Let's see a common situation, microsoft provides many graph apis to call, when accessing these api, we need to provide access token in request head with matching scope, e.g. https://graph.microsoft.com/v1.0/me requires a delegated api permission of User.Read)

To sum up here, if your web service just required the users in your database to sign in then can be access, id token and access token are both suitable for you because they both contains user name like 'xx@xx.onmicrosoft.com', what you need to do is decode the token and check if the token has expired and whether this user exists in your database(you may set up a mapping between them).

Tiny Wang
  • 10,423
  • 1
  • 11
  • 29
  • Thanks! I think I get what you mean - the web service would just need to know whether the "token" has the required "scope" and just provides information based on that scope. So basically it is Azure AD that handles who and what the user is supposed to do and the webservice just responds to those roles without knowing/caring who the user is - it just knows his access permissions and serves based on that. Did I understand you correctly? – frezq Mar 31 '21 at 17:16
  • Yes, that is. Basicly, how to set the rule of checking if the role is vaild is up to you :) – Tiny Wang Apr 01 '21 at 01:25
  • OK I think the confusion in why I didn't get that is because we have been doing things a little bit differently so it took me some time to realize that there is a difference. The way that the web service currently works is that it uses the username to get a list of items belonging to that user. So it's not really about a "role" or "scope" but more like: "OK this user is John so I need to return John's tasks" or "This is Mary, so I find from the database, all the tasks belonging to Mary to send to her". That's why I needed to compare the Azure ID to the Users table in the web app. – frezq Apr 01 '21 at 10:31
  • Oh, I see. You can update it in your question. And as I mentioned at the end of my answer, you may set up a relation ship between the user accounts in your database and azure ad tenant users. But it need to set up according to the real situaltion. E.g. user John has the account John@gmail.com in azure ad and has the id 'J00279' with userName 'John' in the database. You can substring the the email address to match the userName stored in database, then you'll get userId and gather John's tasks with it. You can even create a new table to store the relationship between ad accounts and database id. – Tiny Wang Apr 01 '21 at 13:51
  • Yes you're right about matching. There are a few ways we can match the Azure AD account to the database user and that will require getting some info from Azure most probably as a claim. Looking at this from high level again, I think my main block is how does the webservice validate that the token is coming from the mobile app.. I think that's where I am stuck. Looking at your original answer you mentioned I have to decrypt the JWT token to get the claim but how do I *validate* the token which is the main security concern - How do I make sure it's really from Azure and not a fake token. – frezq Apr 01 '21 at 16:10
  • 1
    Good day sir, I think [this answer](https://stackoverflow.com/a/39870281) could answer your question. In my opinion, you can validate 'aud' claim to check if the token is generated by your specific azure ad application. As you know that id/access token both need azure ad app to generate. – Tiny Wang Apr 02 '21 at 01:38