I 'm creating a bot that running on telegram chanel. when user chatting with bot, it need to know who is chatting. so they must authenticate on my server.
i imagine that bot will send a button have a link of my authenticate endpoint (eg: https://localhost:8080/auth?code=abcd123a). user click to button then open the link in a browser that user logged in. Bot will know user identify because Bot and Server is using same database. But how bot know when user clicked to the link and be authenticated?
and is this pattern is effective (about the delay or UI)?
You could add authentication to your bot via Azure Bot Service via OAuth identity providers. Does your authenticate endpoint support OAuth? In that case, your flow will be:
Bot sends OAuth card, redirecting to your authenticate endpoint.
User logs in, OAuth server redirects to Bot Service token endpoint.
Bot Services retrieves token and handles token life-cycle.
Bot retrieves the activity with the token and can use it for authentication.
Read more about the Bot Framework Token Service.
The Azure Bot Service takes care of the OAuth controllers and login links, stores the target client IDs and secrets, and performs user token management. Otherwise, you would need to do all this overhead yourself in your own hosted OAuth controllers + manage the token life-cycle.
Related
This is a generalized concept question concerning obtaining information of the user in the bot chat. Preferably this would be through OpenID and to start with using Microsoft Accounts. We would want to be able to read User Display Name, User Email address, User Group Membership, etc. What is the best way to obtain this information in Azure Bot Framework? In MVC using OpenID to obtain ClaimsPrincipal is easy, but can this concept be used in Azure Bot Framework and are there any examples of this process?
There was a lot that went into this, but essentially I used an OAuth Connection on the Bot service to send the user to AADv2 endpoint to obtain the token. I then used that token to send to the GraphServiceClient method (part of Nuget package Microsoft.Graph) to obtain User information. This was granted by giving the app in Azure AD MS Graph User.Read API permissions.
We are developing the bot application using Microsoft Bot framework and decided to use a website as a channel.
Question is, our website (Channel) is secured with Azure AD Authentication once user is logged in the website. How we can use the same authenticated user token for the Bot to authenticate the user.
Thanks
Here's a Web Chat sample that shows how to do Single Sign On (SSO) for apps that use Azure Active Directory (AAD)
Note that this is not an easy task, but it is possible.
For other users not using AAD:
SSO for Enterprise Apps sample
SSO for Teams Apps sample
I have a bot running on a hosting page where users are logged in using SSO.
I want to authenticate the user in the bot automatically when the bot starts and I do not want to use anAuthCard to do it. Just want to automatically authenticate the user without prompting anything to him, just using SSO.
I found an article that refers three ways to authenticate an user in the bot:
Sharing the client's user token directly with the bot via ChannelData
Using an OAuthCard to drive a sign-in experience to any OAuth provider
A third option, called Single Sign-On (SSO), that is in development.
And, according to the article my situation is:
WebChat in an authenticated website where the user is already signed in and the website has a token to the same identity provider but to a different app that the bot needs -> in the future, this is single sign-on, but for now you 'll need to use an OAuthCard.
Is there any update about this functionality? How can I authenticate the user into the bot without using an OAuthCard or a SigninCard?
Thanks in advance
Not sure if you have tried the option of using WebChat with Azure Bot Service’s Authentication which provides built-in authentication capability to authenticate chat users with various identity providers such AAD, GitHub, Facebook, etc.
If you are looking for this built-in feature, then probably you need to build your own custom built solution using Google sign-in by passing the token ID of the authenticated users. Or for an Account linking OAuth2 solution as explained in this link: How to implement Login in Dialogflow chatbot.
Microsoft guys Are looking at the issue now. you can track the progress here.
I implemented a solution that worked for me. I have the bot running in a .net core web app
Here's what I did:
Generate an userId before initializing the BotApp
When the user clicks on the button to open the webchat, I'm opening an authenticated controller in a popup that receives the generated userId. The page is authenticated, so you will need to authenticate. I store the userId in my DB, along with access_token and some user information. The controller should be created in the same webapp where the bot is running.
After storing all the information I close the tab and start the BotApp with the generated userId
In bot code you will be able to query your DB (using userId).
To wait until the popup close, you can have a look into this here.
I hope that this helps someone.
Best regards
I will draw a scenario, and need some suggestions:
I'm using Azure AD (v1.0 endpoint), a single-page app (SPA) and a web API. The SPA establishes the user's identity using OpenID Connect, authenticates the user and receives an id_token and access_token for the back-end web API.
Now, we don't want the SPA to do access control decision based on the id_token received within the SPA app.
Instead, the SPA sends the access_token to the back-end web API to access it, and now we want back-end web API to make an access control decision based on the roles claim found in the id_token, but which the back-end does not receive from the SPA.
The question is, is it possible for the back-end web API to send received access_token to Azure AD token endpoint and receive the relevant id_token for the user so that the back-end web API receives an id_token containing the roles claims for the user, in order to make an access control decision?
There are a couple issues with the approach as you describe it:
The app roles would be defined on the native client application (the SPA). Though you can technically define app roles in the manifest, you'll notice the Azure portal won't let you assign users or groups to a native client app. (Which sort of makes sense, because, as you've rightly said, you don't want to do any access control in the native client app.)
You can't do what you've described (exchange an access_token intended for one audience, for an id_token intended for a different audience). There are some variants of token exchange which you can do, but none of them would help you in this situation.
Instead, what you should do is define the app roles on the web API. Then, assign the users to the corresponding app role for the web API. When these users sign in to the SPA, and the SPA gets an access token on their behalf to the web API, you'll notice the access token will contain the roles claim, populated with the appropriate values.
Summarizing:
Under App registrations for the web API, define your appRoles in the app manifest (or on the Application object directly, using (for example) Azure AD PowerShell).
Under Enterprise apps for the web API, assign users and/or groups to their corresponding app roles, and choose whether or not app role assignment is required or not*. (Or do so directly on the ServicePrincipal object.)
Under App registrations for the SPA (the Application object), add the web API as a required permission.
*If you choose to require app role assignment for the web API (under Enterprise apps > Properties), the SPA will not be able to get an access token for users who are not assigned to an app role for the web API. If you choose not to require app role assignment , users who are not assigned an app role will be able to sign in to SPA and the SPA will be able to get an access token on their behalf for the web API, but the access token will not contain a roles claim.
Trying to get my head around the Identityerver4 setup for my project. I have a mobile app where users should be able to login with either facebook or username/password. Facebook login is implemented using the native facebook if available on the device. This results in a token from facebook. With this token I want to request an access_token and refreshtoken (hybrid flow) to access my api (resource). At the same time, some users will also log in unsing username and password.
As I need some info about the user, my plan is to user ASPNET Identity but I'm not sure how to make it wotk together with IdentityServer and If user profiles should be created in Identity based on both logins (registration). It seems obvious for the username/password login, but what about my social facebook login. Later there might also be a web client. So my basic question is how to handle the user registration with both setups