Apple launched “Sign in with Apple” a few years ago. Like Facebook and Google’s similar options, the feature allows users to sign in to apps and websites using their Apple ID instead of creating a unique account for each app or site.
Unlike other options, Apple allows users to choose whether their email address and related information are shared with each app / site. If a user chooses not to share this information, Apple will create a unique unique address to present to the app / site and forward any mail to the user’s actual email address.
While the feature is useful, protects privacy and is widely accepted, it only supports personal Apple IDs. For apps and services used at work or at school, users must either use their personal Apple ID or create an account using their corporate or school email address.
This fall, Apple is expanding sign-in with Apple to support managed Apple IDs, created by an employer or other organization and managed through Apple Business Manager, Apple Business Essentials, or Apple School Manager. In addition to making it easier for users to login to business or education apps and websites, Apple sign in to Work & School allows IT administrators to determine which apps and sites users can use the feature with and restricts access based on users, groups or roles. Organization.
The feature will help streamline account creation and management for both users and IT. The ability to apply access controls through this approach will make IT administration much easier for in-house apps ranging from simple enterprise apps like Slack, as well as commonly used internal or external websites.
From a user’s perspective, signing in with Apple will be just as much an experience as it is today. When signing in with Apple at work and school is enabled, however, users will see a slightly different dialog when they click the “Continue with Apple” button. They won’t have the option to hide their email and will see a notification labeled “Get the right access” that tells them the app will enforce access control based on their business or education account.
The following pane of the account setup process will display their name and the email address used on the app or site. (Apple IDs operated without an email address, such as a student account, will only display their name – an email address is not required.)
Users do not have to enter their account information. The service will automatically use the managed Apple ID associated with the device they are using.
Developers must choose to support this feature
On a basic level, developers don’t need to support this feature outside of signing in with Apple. However, Apple strongly recommends that developers include the company’s new roster API and a new feature called Organizational Data Sharing. Allows you to control access to supported apps or sites. This makes it much easier and more efficient for IT to manage accounts related to apps or sites
Developers need to take some action. The first is to enable the feature in the Apple Developer program using their account, which can be done on the Apple Developer website. The second is to implement Apple’s new roster API.
This API allows a developer’s app or website to ask an organization for user, group, and role information. This is associated with organizational data sharing, a feature that integrates with Apple Business Manager, Apple Business Essentials, or Apple School Manager. This is where IT administrators agree to share user, group and role information with the app / site. In addition to sharing that information, access controls are supported based on any one of those features.
What IT should do
IT administrators also need to take some steps. The first is to decide whether they want to sign in to Work & School for all apps and websites that support signing in with Apple, or to create a list of supported apps and sites. These options are selected in Apple Business Manager, Apple Business Essentials or Apple School Manager.
If an administrator only wants to support certain apps and sites, they need to use a search box to identify and select the apps and sites they want to support. If a user tries to sign in with Apple with an app or site that is not supported, they will receive an error message and have to use another option to create an account with that app / site.
If a developer implements a roster API, administrators must consent to the sharing of organizational data. Again, there are options to support all apps and sites or to limit support to specific apps and sites. Administrators will again use Apple Business Manager, Apple Business Essentials, or Apple School Manager to manage consent for organizational data sharing.
Will the possibility be realized?
Apple calls this feature an extension for signing in with Apple Technically, this is an accurate description, but I think it’s an extension of managed Apple IDs. The real power is that it allows administrators to leverage Apple IDs managed to control access to apps and services (sites) as opposed to manually manipulating each app or service / website.
In this case, the properties offer many possibilities. The question is whether that possibility will be realized in reality. The answer to this question really depends on whether the developers are willing to give time and effort to support the roster API. This is a bit of an open question.
I hope that education developers will be most likely to implement the Roster API, as it provides a clear value-addition for their primary customers – the school.
For business solution developers, the potential is a bit vague. Many business developers support multiple mobile, desktop and web platforms. This means that the extra value cannot be translated into most of their customer base. Still, this is a relatively simple addition which means it can be worth the effort. We have to wait and see.
As I mentioned elsewhere in ComputerWorld’s WWDC coverage, however, it is gratifying to see that Apple is noticing many IT pain points, including IT-related processes and workflow inefficiencies, and is actively working to provide them with creative solutions.
Copyright © 2022 IDG Communications, Inc.