In this demo, we will show you how to authorize a user to access resources on an Intranet app with a bot. We will use Azure Active Directory for OAuth provider and Microsoft Graph for the protected resources.
When dealing with personal data, please respect user privacy. Follow platform guidelines and post your privacy statement online.
This sample is a simplified and reduced version of the sample “Single sign-on demo for enterprise apps using OAuth”. There are notable differences:
This demo does not include any threat models and is designed for educational purposes only. When you design a production system, threat-modelling is an important task to make sure your system is secure and provide a way to quickly identify potential source of data breaches. IETF RFC 6819 and OAuth 2.0 for Browser-Based Apps is a good starting point for threat-modelling when using OAuth 2.0.
You can browse to https://webchat-sample-sso-intranet.azurewebsites.net/ to try out this demo.
This demo integrates with Azure Active Directory. You will need to set it up in order to host the demo.
To host this demo, you will need to clone the code and run locally.
If you want to authenticate on Azure Active Directory, follow the steps below.
http://localhost:5000/api/oauth/callbackas the redirect URI
/web/.envwe saved earlier
/web/.env, it should looks be a GUID
We prefer using Bot Channel Registration during development. This will help you diagnose problems locally without deploying to the server and speed up development.
You can follow our instructions on how to setup a new Bot Channel Registration.
When you are building your production bot, never expose your Web Chat or Direct Line secret to the client. Instead, you should use the secret to generate a limited token and send it to the client. For information, please refer to this page on how to generate a Direct Line token and Enhanced Direct Line Authentication feature.
During development, you will run your bot locally. Azure Bot Services will send activities to your bot through a public URL. You can use ngrok to expose your bot server on a public URL.
ngrok http -host-header=localhost:3978 3978
az bot update --resource-group <your-bot-rg> --name <your-bot-name> --subscription <your-subscription-id> --endpoint "https://a1b2c3d4.ngrok.io/api/messages"
webfolder, run the following:
/bot/is the bot server
/web/is the REST API for handling OAuth requests
GET /api/oauth/authorizewill redirect to Azure AD OAuth authorize page at https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize
GET /api/oauth/callbackwill handle callback from Azure AD OAuth
GET /api/directline/tokenwill generate a new Direct Line token for the React app
This sample includes multiple parts:
.env files hold the environment variables critical to run the service. These are usually security-sensitive information and must not be committed to version control. Although we recommend keeping these keys in Azure Vault, for simplicity of this sample, we would keep them in
To ease the setup of this sample, here is the template of
OAUTH_CLIENT_ID=12345678abcd-1234-5678-abcd-12345678abcd OAUTH_REDIRECT_URI=http://localhost:5000/api/oauth/callback DIRECT_LINE_SECRET=a1b2c3.d4e5f6g7h8i9j0
To reset application authorization, please follow the steps below.
To make this demo simpler to understand, instead of refresh token, we are obtaining the access token via Authorization Code Grant flow. Access token is short-lived and considered secure to live inside the browser.
In your production scenario, you may want to obtain the refresh token with “Authorization Code Grant” flow instead of using the access token. We did not use the refresh token in this sample as it requires server-to-server communications and secured persistent storage, it would greatly increase the complexity of this demo.
To reduce complexity, this sample is limited in scope. In your production system, you should consider enhancing it and review its threat model.
?prompt=nonefor refreshing access token silently through