I want to enable Multi Factor Authentication for specific apps registered in okta through api.I found Factors api but in that the MFA was enabled for a user. I want to enable MFA for some specific apps only. Is there a way to enable MFA for certain applications through api.
You can use application sign on policies to enable MFA enrolment at application level. You can find more details below:
https://help.okta.com/en/prod/Content/Topics/Security/App_Based_Signon.htm
Related
I need help integrating Azure AD B2C and Google APIs. Briefly, I created a tenant on Azure AD B2C, policies and a Native App. Users can register to my app and sign in without any problems. Now I need to use Google APIs to access the logged-in account's information and manage some information (Google MyBusiness data). How can I achieve that. Is that possible ?
Furthermore, even if that is not connected to Azure AD B2C, how can I request to the user to accept that my app to view MyBusiness data?
UPDATE: I understand that I need to authorize my app to https://www.googleapis.com/auth/plus.business.manage Google scopes. Is it possible to request that scope during Google SignIn application authorization process?
Thanks everyone.
As part of the authentication exchange between Azure AD B2C and Google (as well as other identity providers), an access token is issued by Google for use by (and only by) Azure AD B2C, where this access token is used by Azure AD B2C to access the authorized information for the authenticated end-user.
Currently, Azure AD B2C does not pass this access token through to the relying party application (i.e. your native client application), therefore applications can't access the information for the end-user.
UPDATE on 20 June 2019
Using a custom policy, you can pass the access token from the external identity provider through Azure AD B2C to your relying party application.
From the official Azure AD B2C FAQ:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-faqs
Can I configure scopes to gather more information about consumers from various social identity providers?
No, but this feature is on our roadmap. The default scopes used for our supported set of social identity providers are:
Facebook: email
Google+: email
Microsoft account: openid email profile
Amazon: profile
LinkedIn: r_emailaddress, r_basicprofile
Newbie question here on Authentication. I am used to incorporating authentication into my app backend server, like Spring Security Authentication for example. I don't really understand how the authentication providers work.
My concern is that somehow each provider can only authenticate its own accounts, ie google can only authenticate for gmail accounts, and Azure Active directory can only authenticate some kind of Microsoft registered account? I am disinclined to oauth because as a user I am always paranoid about signing in for some game or app from an unknown provider becacuse I never am sure whether I just gave my gmail or facebook account password to a rando.
I am fine giving people the option to use Oath, but less comfortable if that's the only option. I would like people to be able to give me whatever email address they want, and a password which they create for my site only.
Also these questions: If I use an authentication provider can I get the actual email address being used to log in? Or do I only get a token?
If I am going to build my own authentication service so I can accept any email domain as user name, what is the easiest to implement in Xamarin forms, and can somebody point me to a tutorial or something?
Advice appreciated thanks.
Yes, you're right, each identity provider provides the ability to authenticate their own users; Google OAuth supports Google accounts, Azure Active Directory supports Microsoft work & school accounts, Microsoft Account supports Microsoft personal accounts, and so on.
You have quite a few options on how to add support for these identity providers in your app, in addition to what we typically call 'local accounts', or accounts created specifically for the given application. I'll list out a few approaches:
You can write all the code yourself to integrate with each identity provider individually, and build-your-own local account solution as well.
You can use an SDK/library in your Xamarin Forms which facilitates using multiple identity providers within your app. The Xamarin.Auth package has historically served this purpose for Xamarin apps. It provides auth capabilities for Facebook, Google, Microsoft, and Twitter.
You can use a dedicated cloud service which provides authentication services for your app. Some examples include Azure Mobile Apps, Firebase Auth, Gigya, and more. The exact identity providers supported and the level of support for Xamarin/Xamarin Forms will vary across each one. Azure AD B2C is another option that I know supports Xamarin Forms as well as Facebook, Google, Twitter, and local accounts (disclaimer: I work on AAD B2C). These services sometimes have free tiers & paid tiers, so you can compare & contrast each.
You could also build your own authentication service using open source code like Identity Server if you wish.
It definitely depends which route you go, but generally speaking each solution will provide you access to some user profile information upon user authentication. For Azure AD B2C, you can configure the claims that are returned to your application in the tokens your app receives. For other services, you may need to make a REST API call to get some user data like the email address.
HTH.
We're trying to figure out how to submit to the marketplace, but are not sure what we need to do to alter our existing signup flow to accomodate the SSO requirement
Our app was not originally built to be a marketplace app so our signup flow is built for individual users. We are already following the OAuth2 flow as outlined on this documentation page. However, its not clear to me how this works for an entire org when installing from the context of a marketplace app.
Does the admin grant access to all the individual scopes we currently request for the entire org at once? Is there need for some sort of service account or something since we currently are requesting offline access? I'd like to understand what changes we need to make to our server's signup flow in or whether it is just a scope / manifest mismatch.
We currently request the following scopes from an individual user when signing up.
['email', 'profile' ,'https://mail.google.com/', 'https://www.googleapis.com/auth/calendar'],
Exact questions are...
What (if anything) do we need to do to alter our current individual-focused signup flow to accommodate a Google Apps Admin signing up their whole domain?
What scopes do we need to in our Google Apps Admin listing and how do they relate to the scopes we currently request from individuals?
There are not so many changes if you are already using three legged OAuth2.
The first change would be in you project in the developer console. There you need to enable the Marketplace SDK and make the necessary configurations. Here you will add the scopes that your app will request and those are the scopes that the admin will see when installing the app.
The admin will see the scopes your app is requesting, and he will decide if it's ok to install the application in the domain. If it is approved, then yes, the admin would grant access to the entire domain.
Offline access is part of the Oauth flow, after you receive the refresh token, you can continue refreshing the access token without having the user to grant access again.
It is not necessary to have a service account. The service account has two purposes:
To manage information related to the application. In this case the service account can have access to it's own drive to store and retrieve information that is related to the app functionality.
Impersonation of users. When using domain delegation of authority, you can use a service account to impersonate any user in a domain and act on it's behalf to make API calls.
To deploy your app, you also have to create a new project in the Chrome Web Store, with a manifest for Marketplace.
To answer your questions:
It's not necessary that you modify your current oauth flow. The admin will install the app in the domain, but when a user access to the app, the process for authentication is the same as individual.
The scopes in your Marketplace SDK configuration should match the scopes your app will use. This is mostly for security reasons, it wouldn't be safe if you install an app with some scopes and then the app uses different scopes.
You can try your app before actually deploying it by adding trusted testers in the chrome web store dashboard or in the Console API configuration. This way you can check if your flows and all the configurations were done correctly.
Hope this helps. Let me know if you have more questions.
I have attempted to publish an application to the Google Apps Marketplace that uses a service account to act on behalf of users within a domain. How does the installation flow differ based on whether the installing user is an administrator or a normal user since it requires the service account to be authorized in the Google Admin console?
I am getting push back during the application review asking why the app is requiring an admin to manually authorize the API scopes for the service account in the Google Admin Console. If a Google Apps Administrator installs the application for the domain and consents to all of the application access, does that authorization apply for all users in the domain? I do not want all users in a domain to be prompted with the OAuth 2 consent screen.
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!