I am adding Microsoft Account authentication to my web application. We need to store extra information about the signed in user to a DB. What id can I use for the user to associate this data with? I am assuming it is either the oid, tid, or sub.
You should use the user account OID or a combination of that and another property as its OID is globally unique.
Related
I have a bot service which integrates with Teams. All the interactions will happen via Teams. Their access to Teams serves as their authentication into our system.
The question is whether I should use the Teams ID or the Azure Active Directory (AAD) Object ID as the unique identifier for that user. What are the pros/cons of each? What are other considerations I should factor in. Is either of them more likely to change? What am I not considering that I should be considering?
In simple terms, either one is fine as long as it uniquely identifies the user, and both are "Ids" so they do that. However, the one is purely from a bot perspective, and so it's not even Teams-wide. For instance, if you add a tab to your app later, you'll only get the user's AAD Id, and that's presuming you don't -ever- want to do anything more broadly. So I'd strongly suggest, given the option, to rather use the AAD Id.
Azure Active Directory (AAD) Object ID is the best way to uniquely identify the user.
Also Multiple Teams can contains same users, so if you need a requirement where you want to uniquely identity the user's in different Teams, you can use a custom combination of (Team Id + AAD Object Id).
I'm implementing authentification for a Xamarin application using Azure B2C.
To signup user we will need the user firstname, last name and his email.
later in the application the user will be asked to add his address and his user photo.
Should I add the user address and photo to be saved in the B2C or I should keep them saved in the application data base?
what is the user unique identifier that I should share between B2C and application data base? should I use the email or the userId?
In the auth token you receive back from Azure AD, you have an object ID that is unique to each user.
The B2C token is slightly different to the regular AD token, you don't get back all the values listed in the Token Reference (e.g. Groups, you have to query for these separately), but you will get the object ID that you can then use to lookup your DB.
Please visit here for further reference.
You can decode your JWT token here to see what you get back: https://jwt.io/
Hope it helps.
I need to check whether a provided user name is a local or domain user in VC++. I thought LookupAccountName was going to give me what I needed because of the last argument. I used it to get the SID from an account name, it works perfectly fine and gives me the correct SID, but not he correct SID_NAME_USE. The website says:
peUse [out]: A pointer to a SID_NAME_USE enumerated type that indicates the type of the account when the function returns.
However peUse is always SidTypeUser no matter what type of user I supply (local user or domain user). I also tried with LookupAccountSid and I'm getting the same thing. Here are my questions then:
Can I use LookUpAccountName or LookupAccountSid to get the correct account type?
Why is the function always returning SidTypeUser as the user type?
Is there any other way to check whether a user is domain or local user from its SID or username?
Please someone help me, I have stuck on this for a while now.
Thanks!
Use LsaQueryInformationPolicy with PolicyDnsDomainInformation to retrieve the SID for the computer's primary domain. (If the Sid member is NULL, the computer is not joined to a domain.)
Otherwise, use LookupAccountName to retrieve the SID you are interested in, then use GetWindowsAccountDomainSid to extract the domain part of the user's SID.
Compare the primary domain's SID to the user's domain SID using EqualSid. If the SIDs are equal, the user is logged into a domain account; otherwise, the user is logged into a local account.
I am authenticating a user in my windows phone using live sdk.now I want to generate user I'd for that particular email login the back end.is there any standard or Apis within wp sdk which I can use To generate userid for that particular email login
There are no APIs to generate User IDs. This is completely up to you on how to implement this. You can simply use their email address as their User ID since it will be unique for each person. Or you can generate a random GUID using Guid.NewGuid().ToString().
If you want to tie the user to their device then you can use the device unique Id using DeviceExtendedProperties.GetValue("DeviceUniqueId").ToString() However note this value will never change so you will always want to check both email and the device Id in case ownership of device is transferred.
I'm trying to implement OpenID authentication for my site. Here's the scenario:
I want the user to be able to
login using just openId(user can just get verified by visiting openid provider. no need to create a custom account with email-password),
Via email/password (user has registered in site by filling out a form)
Attach open id(s) to his/her accounts (openids + email for one account).
Now I don't know what credentials I should store for open id. and not sure about the DB schema. Here's the database schema:
Table: Users
UserId => PK
... => Custom info. Not related to authentication.
Table: Authentication
AuthenticationId => PK
LoginId => (when custom site membership => email address) (when openId => openid unique address)
UserId => FK to Users.
Provider =>(when custom site membership => "CUSTOM") (when openId => openid provider address)
Password => filled when using custom membership. empty when using open id.
Now when a user logs in, whether by using openid/custom membership, I just look at authentication table and look for credentials and get the appropriate user. If no users exist, I create a new user and add an entry in authentication table.
The main question: Is storing Provider and LoginId (see the above comments to see what is being stored in these fields) enough for storing openid authentication? Should I store any additional data so that when the user returns I can authenticate him/her based on my saved data?
Do you suggest any other (more efficient) approach to implement this?
Thank you.
Store the ClaimedIdentifier for the openid user--not the Provider address. The Claimed Identifier is what the OpenID protocol verifies is unique for the user and also potentially provides portability across OpenID Providers.
Also, because OpenID 2.0's Claimed Identifiers may be deprecated by OpenID Connect (an unfinished successor to OpenID 2.0), it may also be in your best interest to record the OpenID Provider Endpoint URI and the email address asserted by the Provider in the user record. For now, do not use these as part of your authentication flow, but by recording them, you'll be able to later determine which email addresses you 'trust' (i.e. suppose you decide email addresses asserted by Google are trustworthy) and allow the user to thereby migrate their account to an OpenID Connect one using that verified email address. This will also mitigate against the danger of your web site's Realm (usually http://yourdomainname.com) changing and causing all your Google's user Claimed Identifiers to change, which can only really be recovered from via their email address, tragically.
I also recommend you use different tables for the different auth types. There are a couple of advantages here. The most important one is that architecturally it makes it more difficult to have introduce a security hole into your web site that might allow someone to enter in (for example) an OpenID into the username field and a blank password and have it show up as a database match and login without any real authentication happening. Secondly, it provides a more flexible model in case you want to add a third authentication mechanism rather than making your 'Authentication' table grow horizontally for all users. For example, OAuth 2.0 and "OpenID Connect" will each probably introduce new types of authentication to your site when you add support for them over the years, and adding new tables to handle the new types of data seem to fit better.
We just store the openid claim url. You may want to request additional information from the provider such as the user's name. The most important thing is to separate membership and authentication.
Our schema was
Profiles
--------
UserId
FirstName
LastName
etc.
Users
-----
Username
Password
Profiles.UserId is simply a string property that stores either the users internal username or their openId claim url, depending on how they registered.
Upon successful authentication (either using an internal username/password or external provider) we just set their authentication cookie using either their internal username or their claim url. Getting the user's profile is then just a matter of finding the profiler where (UserId == User.Identity.Name).
This has the advantage that a user can choose to change how they authenticate at any point (perhaps switching to an internal account or using a different provider).