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.
Related
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
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
I am trying to run the active-directory-dotnet-webapi-onbehalfof sample in single tenant mode. I've registered the web app service and the native app client as global admin for the tenant. When I run the sample, as a user in the tenant, I can get a token in the client only after consent pops up (first-time for user), and then call makes it to the service, but there it fails with below. Why is that? Documentation says that when a tenant admin registers the application no further consent is needed? I don't think it is possible to give consent when a remote webapi tries to get OBO token. Something seems buggy... AAD team, please clarify how the OBO feature should be used.
AADSTS65001: The user or administrator has not consented to use the application with ID 'b824502e-fe8a-4770-bd98-8d65a07efcc3'. Send an interactive authorization request for this user and resource.
Trace ID: ad7843d0-be4e-4098-8f7c-43c8e5505cfc
Correlation ID: 140466a4-7250-429f-8843-dbd4f63dc60e
Timestamp: 2016-11-25 21:46:13Z
When you register an application using the Azure Management Portal (manage.windowsazure.com) as a tenant administrator, then yes you should not get consent, as long as subsequent tokens are being retrieved in that same tenant.
Because you are seeing consent for the native client app, and then getting that error message, we must assume that something is not being satisfied which would suppress consent for your app.
To resolve this issue, my recommendation is to simply initiate an interactive authorization request just like the error message implies. You can do this by generating a log-in url for your application, with a specific query string that will force prompt tenant wide consent (prompt=admin_consent).
Here is the skeleton for the URL you need to complete:
https://login.microsoftonline.com/<TenantID>/oauth2/authorize?client_id=<AppID>&response_type=code&redirect_uri=<RedirectURI>&resource=<ResourceURI>&prompt=admin_consent
You can do this for all the applications you registered, and you should not run into consent issues (assuming you are indeed signing in as a tenant admin).
I hope this resolves your issue.
We publish an app that use OAuth 2.0 API access on Google Apps Marketplace. It got reviewed by Google and they said our app is invalid because it shows permission screen when a user first runs the app. (The app will be removed from the Google Apps Marketplace if our app is not fixed within 30 days) To solve this issue, we have some problems.
Our app uses OpenID Connect to make users login.
Our app also uses Spreadsheet API and Calendar Resource API (OAuth 2.0 Web Application Flow)
So our questions related above is the followings:
1.
Although our app uses OpenID Connect for login, using OpenID Connect forces our app to show the permission screen. Doesn't it meet the best practice below of Google Apps Marketplace?
https://developers.google.com/apps-marketplace/practices#5_use_one-click_single_sign-on
We followed the OpenID Connect document provided by Google:
https://developers.google.com/accounts/docs/OAuth2Login
2.
Since Spreadsheet API and Calendar Resource API don't currently support the authentication method using Service Account with OAuth 2.0, we chose to use the method of Web Application Flow. Our app get the token when users login, but Google said to us that it fails to meet their SSO requirements. To solve the issue, we are thinking to change our app to authorize AFTER login within the app instead (use Web Application Flow method as it is). Does the way meet the SSO requirements? In other words, is it OK to show permission screen if after login?
We will applicate if anyone can tell us good solution to solve these problems.
Thanks,
If you register your scopes in the Google Apps Marketplace configuration screen, and then only request those scopes in the OpenID Connect flow, then the permissions screen should be automatically skipped. Please ensure the scopes match between these two locations.
I just create my first Okta application using a dev account.
The app supports saml2.0 to authenticate user.
My goal is to make Okta app as a smal2.0 IdP and having my on-premiesis web app acting as a SP. The flows works great.
As first step to test the flow I created a "user base"(people) in Okta.
Would it be possible to engage from Okta app a custom api (on-premesis) to validate the user credentials (supplied within the Okta built-in login page)?
IOW I'd like to use Okta app simply as saml2.0 IdP, managing the saml2.0 protocol, but I'd like to keep the user base locally.
We do provide SDKs to interact with our API, and you can find them at http://developer.okta.com/docs/sdk/core/api.html.
For instance, the Okta Music Store available at https://github.com/okta/okta-music-store demonstrates how you can authenticate Okta users in an ASP.NET MVC app and automatically provision them into a local database "on the fly" when they sign in.
I hope this helps!