When I call agent.logout(...) with the account that I logged into my application with, I get logged out of my application but I am also logged out of Outlook on the web that I have open in another tab.
How do I logout of only my application (registered in AAD 2.0 of course) but not logout of Outlook on the web? I provide the "account" that I logged in with that should be tied only to my specific application.
This is intended behavior, given both applications rely on the same AAD session. If you would like to only remove the session information for the MSAL instance on your website, you can manually clear local/session storage, instead of using the MSAL logout API (which will send the user to the AAD logout screen).
If you would like the ability to configure logout to only clear browser storage and not making a network request to the AAD logout page, you can open a feature request on the MSAL.js Github repository.
I think that makes sense. I guess I'm not familiar with how AAD sessions overlay/influence the oauth process. I'll open up a feature request. Thanks
Related
After I try to launch an app using the Okta dashboard, I have a problem; it displays old user information (perhaps because the local app token is unclear when we sign out of the Okta dashboard).
Scenario
Sign in with user A to the Okta dashboard.
Use the Okta dashboard to launch my application
Exit user A from the Okta dashboard.
Sign in with user B to the Okta dashboard.
Run my application through the Okta dashboard once more (here it shows me User-A details)
So, is there a way to deal with this circumstance?
What is expected to happen?
It should show me the User-B details on my App
SDK Versions
#okta/okta-auth-js: ^6.0.0
#okta/okta-react: ^6.4.3
Execution Environment
macOS, Google Chrome, React (typescript)
I use Okta Sign users into your SPA using the redirect model
Thanks!!
I believe the issue is on your application side and in your expectations.
OIDC with Okta does not have a way to inform your application, that user A signed out of Okta. You need logout flow to be initiated from your application end.
So your app holds a token from user A and never had a chance to know, that in Okta user A logged off.
But my question is: does the fact that a user signed out of Okta mean that their identity changed?! No. So for your app the user is still confirmed legitimate user.
What you are trying to achieve is session management which is a responsibility of an application. Okta only confirms/asserts to your app a user's identity.
I have a web app which sends emails (gmail) in name of my users
When a user registers, she supplies gmail account and password. Also she has to enable access for Less Secure Apps (I recommend to create a new account for this)
Then I can open a gmail session
session = Session.getInstance(props, new javax.mail.Authenticator() {
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication(user.getEmail(), user.getPassword());
}
});
and send emails on her behalf.
Unfortunately this is going to stop working next 30th May, when Google will allow only OAUTH2 access
I have followed Java Quickstart for Gmail API and I have code up and running for sending emails with OAUTH2: enable gmail api, create an application on google cloud platform, grant send permission, oauth2 client id credential created...
The problem I have is I can't see a way to automatize this task because when creating an authorized credential, a consent screen displays on browser and you have to select the account to be granted manually (maybe because my app in google cloud platform is still pending to be reviewed)
Is there a way to infer the gmail account you want to access from the credentials file (client_secret.json)? Is there a way to automatize this?
No, or yes. It depends.
The whole point of OAuth2 is to improve security by working with authorization tokens rather than asking for user credentials. To do this the user has to consent to the app's access request, and thus the OAuth consent screen cannot be bypassed. This is
explained in Google's documentation. It's not related to your app's review status but rather it's the way OAuth works.
You can still work in a similar way, though . Instead of asking for username and password upon the user's registration you can redirect them to the OAuth consent screen so they can authorize your app. Make sure that your app is requesting offline access type and then you can retrieve an access_token and a refresh_token. These will essentially work as your credentials and you can use the refresh token to generate new access tokens when needed without having the user go through the consent screen each time.
The refresh token doesn't have a "natural" expiration so you can keep using it indefinitely, but there are a few scenarios where it will become invalid, such as it not being used for six months, the user changing passwords (if using Gmail scopes), the user manually revoking access, etc. In these cases you will need to direct them to the consent screen again to reauthorize your app.
In this sense, your app can still work automatically without user input except the initial setup, which you already had to deal with when they supplied you with their credentials. The refresh token expiration can even be compared to what you had to do when the users changed their passwords in your current workflow.
One exception to this are service accounts. If you and your users are part of a Google Workspace domain you can delegate domain-wide access to it, then the service account will be able to access user data without any manual input. Of course, this is because as the domain administrator you pretty much own all the accounts under it. But if you're working with a publicly available application you will have to deal with the limitations I mentioned above.
Sources:
Google's auth overview
Using OAuth 2.0 to access Google APIs
OAuth 2.0 for web applications
The OAuth consent screen
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'm looking for a way to auto-login a user that's logged in with an Azure AD user account into a web application.
What I've got so far: A web application that uses an Azure OAUTH workflow to login to the application. The user is forwarded to Azure's login page and after a successful login, he will be redirected to the web application with an oauth code that later used to get the user's identity.
Now I've got a new situation: Windows PC are part of a Azure Active Directory and the users all use AD users. Is it possible to use NTLM/Windows Integrated Authentication to auto-login when they open the page.
I looked for a way to enable NTLM/WIA for the OATUH flow to avoid that a user has to re-enter the credentials that he just used to unlock his pc.
Is there a way to do this?
We have a desktop application that is used to upload content to a web application, both use Okta for authentication. Before uploading, the desktop application authenticates the user via Okta using an embedded browser control. Later in the workflow we want to open the user's default browser so he/she can start using the web application directly. At the moment the user will need to login a second time when their default browser opens.
We planned to implement a mechanism to generate a one-time key (transferable session token) that can be passed as a URL parameter when the browser is opened. For our application's own token we can achieve this but we also need to transfer the Okta session (cookie) and we have not found a way to transfer this from the desktop browser control to the standalone browser.
What options are available to achieve this?
Edit: it is acceptable if a new session is created for the standalone browser as long as the user identity stays the same and the user does not have to provide login details a second time.
Unfortunately, Okta does not have a way to transfer one active session to another as you describe.
However, if you have enough control over the organization's environment, you could simulate this behavior. For Okta organizations that use IWA to authenticate users, you would get this sort of feature "automatically" (provided that the user's default browser supports Active Directory). Another way could be to configure your web application as a "SAML IdP" and have it "transfer a session" to Okta using a SAML Response and Okta's Inbound SAML functionality.