Discover Sign in with Apple at Work & School

♪ instrumental hip hop music ♪ ♪ Hello. My name is Ashwath and I am an engineer with the Education team.

Today I am excited to talk to you about Sign in with Apple at Work & School.

In this presentation, I will be covering the key features that we are introducing this fall.

I will first walk you through what Sign in with Apple at Work & School is and how it works.

Then I will talk about the Roster API and specifics about how you can make use of it.

And finally, I will be talking about access management, where I discuss how IT admins can manage access to Sign in with Apple at Work & School and the Roster API on behalf of their organization.

Let me begin by covering two concepts you may be familiar with but are important to review for this session.

The first is Sign in with Apple.

Sign in with Apple is a fast and easy way for users to sign in to apps with their Apple ID.

Users are able to create an account within your app with a simple tap.

The second concept is Managed Apple IDs.

Like Apple IDs, Managed Apple IDs are used to personalize a device.

They're also used to access Apple apps and services.

Unlike Apple IDs, Managed Apple IDs are owned by an organization and managed through Apple School Manager or Apple Business Manager.

With those definitions in mind, I am excited to share that Sign in with Apple has now been extended to support Managed Apple IDs.

Now you can get the benefits of a fast and easy sign-in experience of Sign in with Apple, but with the management capabilities of Managed Apple IDs.

To showcase the user experience of Sign in with Apple at Work & School, let us take a look at an example.

Here is the login screen for Slack.

To use Sign in with Apple, a user can just tap Continue with Apple.

When using an Apple ID, they will then see this welcome screen for Sign in with Apple.

On the other hand, if they are using a Managed Apple ID, they will see the welcome screen for Sign in with Apple at Work & School.

You will notice a difference in the welcome screen.

What do we mean when we say we make it easy for apps to provide access control? Let's take a look at an example.

When using their personal Apple ID with Sign in with Apple, the user sees the account creation screen where they may edit their name and choose whether to share or hide their email.

But in an organizational context, it is important for the app to understand who is logging in and what level of access to provide them.

In the example shown on this screen, the user is signing in to Slack at work.

In order to know which Slack channels this employee should be allowed to join, Slack needs to know which user is signing in.

So this is an example of Slack providing access control using the name and email shared with their app when using Sign in with Apple at Work & School.

So this is what the user sees, but what does this mean for you? It means when a user uses Sign in with Apple at Work & School, the name and email fields will always be accessible.

If you are a developer working on a client-side app, here's a look at some example code showing the authorization controller.

On a successful authorization, the highlighted statements indicate the full name and email received by your app.

This assumes that the request for authorization included the scopes for the full name and email.

If you are a developer supporting Sign in with Apple on the web, here's a look at some example code that uses the signIn method to start the authorization process.

Upon successful authorization, the server returns the response to the data object.

That data object looks like this.

The highlighted fields contain the email and full name of the user signing in.

It is important to note a few points here.

In this release, Sign in with Apple at Work & School uses the primary Managed Apple ID that is signed in on the device.

Even though the example screens that we showed you were for the login flow on the device, the web flow is supported as well.

Some accounts may not have email addresses provided.

For example, schools may not assign email addresses to younger students.

Let's see what the account creation screen looks like in this scenario where an email address is not present.

This user, Fatima Silva, does not have an email address, so only their full name is present on the account creation screen.

If you have already implemented Sign in with Apple, there is no work needed from your end to add support for Managed Apple IDs.

If you haven't implemented support yet, I would highly suggest taking a look at the "Get the most out of Sign in with Apple" session from WWDC2020 and the "Enhance your Sign in with Apple experience" session from this year.

That was Sign in with Apple at Work & School, which brings the fast and easy sign-in experience of Sign in with Apple to Managed Apple IDs.

Now let's dive into the Roster API.

But before jumping into any specifics, let's consider the following scenario.

You're a developer in the education space.

Your app is being used by school districts.

You have implemented support for Sign in with Apple in your app.

That's great! Students, teachers, and staff can use their Managed Apple IDs to log in to your app.

In this scenario, your app allows teachers to share assignments and announcements with their students.

To support this, IT administrators need to enter students, teachers, and classes into your app prior to the start of the school year.

For a school with hundreds or thousands of students, creating these records by hand would quickly become a time-consuming and tedious process.

We've created the Roster API to address this problem.

The Roster API provides programmatic access to resources like users and classes in Apple School Manager.

This allows an IT admin to automate the process of importing this information to your app.

These resources are defined in the form of REST endpoints.

This data can be accessed by your app after the IT admin has granted permission through a successful OAuth 2.0 authorization.

The Administrator and Site Manager accounts in Apple School Manager can manage which apps are able to access the data.

As part of this release, we have created a standardized way for apps to request access to organizational data.

We call this Organizational Data Sharing.

We wanted to follow industry standards when it comes to UI design patterns and choice of technology so developer adoption is easy.

So we created an authorization flow using OAuth 2.0, which includes using scopes and asking the IT admin to consent to sharing their organizational data.

Here is what it looks like.

The consent screen provides information on which app is requesting access to the organization's data and what data the app is requesting access to.

Looking more closely, the consent screen contains information on the requestor -- which represents the app requesting access to the data made available by Apple School Manager; in this case, the requesting app is Quizzler -- and the scopes, which represent the data that the app will have access to.

In this case, once the IT admin consents, Quizzler will be able to access all user and class information for this organization.

What does your implementation journey look like? The first step is to register in the developer portal, which involves requesting scopes.

The next step is to request consent from the IT admin to share the data with your app through the OAuth 2.0 authorization flow.

Finally, your app queries the Roster API endpoints to fetch the data.

Let us take a look at each of these steps.

To request scopes, visit the Developer portal.

Under the Certificates, Identifiers & Profiles page, click on Configure under Account & Organizational Data Sharing.

In the next step, click on "Set up a configuration." Choose the primary app ID from the drop-down and hit Continue.

In the additional configuration details page, under Organizational Data Sharing Scopes, choose the scopes desired.

Right now, we offer two: user access and class access.

Ensure return URLs are configured for your app.

This step is important as the return URLs will be used in the OAuth 2.0 authorization flow.

Hit Continue.

Finally, confirm your configuration.

Now we're ready for the next step.

The second step in the implementation journey is getting the access token through the OAuth 2.0 authorization flow.

Let us look at this in detail.

The IT admin first logs in to your app.

The IT admin then interacts with your app to initiate the authorization flow -- for example, by clicking a button named "Connect to Apple School Manager." This starts a sequence of events following the OAuth 2.0 standard.

The first step is to execute a GET API call to the authorize endpoint.

Let us take a look at the details of this request.

The request takes in a few query parameters: the client_id, the redirect_uri, the state, response_type, and scopes.

The response will be a redirect to the Apple OAuth consent screen to request access from the IT admin.

In this diagram, we assume that the IT admin has authenticated with their Managed Apple ID.

If they have not, they would be prompted to authenticate first.

The IT admin is presented with the consent screen to confirm that they would like to share their organizational data with your app.

This is the same consent screen that we saw earlier.

As a reminder, it looks like this.

Once they click Allow, your app is provided with an authorization code at your return URL that you registered in the developer portal.

The final step involves a POST request to the token endpoint to retrieve your app's access token.

Let us see what this request looks like.

The request body is composed of standard OAuth parameters including the authorization code received on your return URL.

The response would have the access token, its expiration, and the refresh token that is used to create a new access token when it expires.

Let us take a look at the request details to generate a new access token using a refresh token.

The request body is composed of the standard OAuth parameters, including the refresh token, and the response would have the access token and its expiration.

After successfully completing the OAuth 2.0 authorization flow, your app now has the access token, which can be used to fetch user and class information from the Roster API.

As part of our current release, we are introducing five endpoints that the apps can query.

These include fetching a list of classes, a list of users, a specific class, a specific user, users in a class.

Let's walk through a simple example flow to demonstrate how you can fetch users and classes.

Your app server can first retrieve the list of students, teachers, and staff by querying the users endpoint.

Let us take a look at the request and response in detail.

The users endpoint takes in three query parameters.

The pageToken and limit are pagination parameters, and an optional role parameter lets you query for students, instructors, or staff.

The request requires the authorization header with the access token generated from the authorization flow.

The response is a JSON payload that includes a "users" key, which has the list of users; the "nextPageToken" key that is used to fetch the next set of records, and a "moreToFollow" Boolean key that indicates if there are any more records to query.

Let's take a look at an example request.

The API call here is retrieving a list of students with a maximum of 10 students in the response.

This is the first API request, so the pageToken query parameter is not specified.

The response has standard user information such as givenName, familyName, etcetera, but I would like to draw your attention to the stable unique identifier for the user.

This is the same identifier your app receives when the user authenticates with Sign in with Apple.

The email address of the user and their roles in the organization are also included.

The nextPageToken needs to be used in the subsequent API request as a query parameter to fetch the next set of students, since the moreToFollow key is set to true.

After querying the users endpoint, your app server can now query the classes endpoint, which gives you the list of classes for that particular school district and the relationship between the class and the students and teachers associated with that class.

Let us take a look at the request and response in detail.

As part of the get classes request, the request takes in two query parameters: the pageToken and the limit parameter, both of which we saw before.

The headers are the same as when querying users.

The response is a JSON payload in which the "classes" key holds the list of classes.

Let us take a look at an example request.

This request retrieves a list of classes with a maximum of 200 to be included in the response.

The API request also has the pageToken parameter, which means it is in the middle of fetching all classes.

The response has standard class information such as the name, the class identifier, etcetera, but I would like to draw your attention to the list of instructor IDs and student IDs that belong to the class.

That was the Roster API.

With these endpoints, your app can now programmatically query users and classes from Apple School Manager.

Finally, I would like to talk to you about access management.

It is vital to provide management capabilities to organizations using Organizational Data Sharing and Sign in with Apple at Work & School.

Let me explain what this means in more detail.

When using Sign in with Apple, users manage their own account and it's solely up to them to decide which apps they choose to sign in to.

But when using Sign in with Apple at Work & School, the IT admin at the organization centrally manages access on behalf of all the users at that organization.

This is because the IT admin is responsible for ensuring the safety and security of the organization's data.

So, they must be empowered to manage which apps users are allowed to use Sign in with Apple at Work & School, and which apps are allowed to use Organizational Data Sharing.

These access management capabilities can be configured in Apple School Manager and Apple Business Manager.

For Sign in with Apple at Work & School, we offer two modes.

The first mode is "Allow all apps." Let us see what this mode looks like.

Here, the IT admin is logged in to Apple Business Manager.

On selecting Access Management from the sidebar and choosing Sign in with Apple, they are presented with the two modes.

The "Allow all apps" mode lets all users of the organization log in to all apps that support Sign in with Apple.

The second mode is "Allow only certain apps." Let us see what this mode looks like.

The "Allow only certain apps" mode lets the IT admin search for apps that support Sign in with Apple to add to the list.

Users will only be able to use Sign in with Apple with the apps that have been added to the list.

If a user tries to log in to an app that is not on the list, they will see an error message.

It is important to note that this functionality is the same for Apple School Manager, Apple Business Manager, and Business Essentials customers.

Similar to Sign in with Apple at Work & School, Organizational Data Sharing also has the same two modes.

Let's take a look.

The "Allow only certain apps" mode lets the IT admin search for supported apps to add to the list.

It is these apps that can access user and class information using the Roster API.

In addition to the consent screen, this is a second layer of control for the IT admin to manage which apps can access organizational data.

With the release of Sign in with Apple at Work & School, now users in any environment can use an Apple ID or a Managed Apple ID to log in to your app.

If you haven't already implemented Sign in with Apple, I encourage you to do so.

I would also highly encourage you to adopt the Roster API if you are in the education space.

Implementing support for Roster API will provide a seamless onboarding experience for IT administrators, staff, teachers, and students.

As always, we love hearing from you.

So please submit any feedback you may have.

If you'd like to learn more, I would highly suggest the "Get the most out of Sign in with Apple" session from 2020 and the "Enhance your Sign in with Apple experience" session this year.

Thank you so much for watching and we hope you enjoy this year's WWDC.

♪