We have a Terms of Service and Privacy Policy on our oauth application, however new users do not have to agree to our Terms & Privacy because we don't require any elevated permissions.
Our oauth has been verified by google, however the consent screen where the user explicitly agrees to elevated permissions and Terms/Service does not come up unless we require additional scope (other than profile, email).
For an example, if you go to www.dropbox.com and authenticate via Google, you'll see the consent screen where they require the user to accept that they will Manage contact list, as well as they need to agree to the Terms and Service. We don't have any elevated permissions so the consent screen doesn't come up, however we need the users to accept the Terms and Service regardless.
Workaround is to just include some random elevated permission, but we'd like to avoid that if possible. Anyone know how we can force the consent screen to show with only the Terms/Service links without having any elevated Google permissions?
You can setup OAuth, which will prompt the customer with a consent screen. The users have to agree to the terms presented on the consent screen.
Otherwise, you can use an in-house solution, that's basically a home landing that requires that they read and click agree on your terms and conditions before allowing them access.
Related
Users on my platform can register with email & password.
When they wish to log back in they can use a 3rd party integration (such as Gmail) to authenticate their email.
I've seen on multiple websites (Zapier for example) that even though I authenticated with the Gmail integration, they still ask me for my original password when signing in.
Why would they need my password if they already authenticated that this is my email?
Is there any security reasons to do so or is it just to make sure that even though it is my email, that I know my password for my account?
There is no need to ask for a password if you connect with a trusted service such as Google, Facebook, Apple, Microsoft, Twitter, etc, and you are in fact delegating all security checks to the respective provider. Google, for example, based on the user's account settings would be responsible with providing the user with a 2FA challenge before logging in.
It would in fact be good UX practice to not even ask the user to create a password and some websites even decide to exclude the creation of local accounts altogether. In this case, the user can just log in with the provider without the need for a "sign up" process because all OAuth providers share the user's email address if requested so you can create the account "on the fly" as needed and personalize the experience by sending a welcome email, redirecting to a page, showing a message, etc.
That being said, you can augment the login security as much as you want with original password requests, CAPTCHA challenges, encryption, IP whitelists, hit counters, cooldown periods, etc, if you feel it's justified. Would it be needed? Probably not in most cases.
Right now I've only requested the permissions required for a user to successfully authenticate into the SaaS application. These are delegated permissions.
I'm now wondering how to handle permissions for a new daemon integration, which will request different data from Graph and require application permissions. So far I see these alternatives:
I create a new application, representing the integration, and if the customer wants to enable this feature they go through the admin consent flow and grant the required application permissions.
I encumber the main app with the 'optional permissions' and tell the customers that if they don't use this particular feature then they can revoke this and that permission.
Are there more alternatives? How are others handling this situation?
I foresee more daemons, requiring different permissions, in the future which makes alternative 1) seem quite unattractive. On the other hand, I can envision push back from AD admins everywhere if I go down route 2) and ask for all kinds of permissions that aren't applicable to that organizations feature set.
Best practices would dictate you have a separate app registration for each application/daemon. That being said, if you don't want to, you could do something between your two options, make a second app registration for all the daemons, and make a simple SPA just to log in to give consent to that app registration, which is separate from the saas app registration.
I would definitely avoid option 2 on your list though, because then the saas application would technically be able to access all the same things your daemon permissions have which can be a big security risk.
We have included list of all applications assigned to a User - as an applications ribbon - in a webpart in sharepoint. We have used this API call to retrieve the applications:
https://alignedenergy.okta.com/api/v1/users/[user#domain]/appLinks
It works fine, but this retrieves ONLY the list of applications that are administrator governed.
Please advice: Why is it not returning the list of all org-defined and user-defined apps/bookmarks for every authenticated user from Okta?
We are in a hurry to complete the integration of OKTA and SHAREPOINT (waiting to release because of this problem).
Thanks in advance.
The reason why user-defined apps and bookmarks are not exposed through the API is because of privacy reasons. We strive to make sure our users 100% trust the Okta platform for handling their personal and sensitive information in the most secure and privacy-aware fashion.
What if a user creates a bookmark that points to a bank site he doesn't want the administrator to know about? We actually allow that and deny the ability even for an administrator or super use account (which is effectively the identity you impersonate with when using an Okta API key) to get access to that information.
Personal Okta apps and bookmarks are in Okta and should stay in Okta for privacy reasons. I hope that makes sense but feel free to send us a note at developers#okta.com if you want to discuss your needs further.
Everything I'm reading shows that in order for an application to use onedrive, it has to do the oauth2 thing to get credentials. But what if you're a batch process and don't have a web interface for your users.
Google's API has a special type of account called a service account where once you set it up, you can control access to everything from that one account, no need to interact with users. Does such a thing exist for onedrive?
App-only authentication doesn't require the user be prompted for credentials but it also isn't supported in 100% of scenarios. For example, the APIs need a user principle for creating special folders and resolving a user's personal site. Also, it is only supported for OneDrive for Business, not Consumer. Consumer always requires the user be prompted for initial authentication.
Another option would be to spin up a web service of some sort that handles initial user authentication, ie. a sign up page. With that, you can retrieve a refresh token for offline authentication and store it for the user. Every authentication from then on can be done using the refresh tokens, which doesn't require a user prompt.
I finally found this. It's the same basic idea as google's service account, but I think it's harder to use. But at least the concept is supported.
http://blogs.msdn.com/b/exchangedev/archive/2015/01/21/building-demon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow.aspx
I've implemented the BetterAuthorizationSample for the hope that the user would not be bombarded with the authentication dialog box for privilege operations. The implementation mostly works, however it does require the user to authenticate once. I want to disable authentication all together. Is this possible with the BetterAuthorizationSample?
Any suggestions?
Thanks.
No.
This completely defeats the purpose of authorization. If there was any way for applications to perform privileged operations without the user's express consent, then malicious programs would be free to do whatever they wish.