Discover Sign in with Apple at Work & School

ハイライト

Apple でサインインは、当初は個人の Apple ID のみをサポートします。このアップデートでは、これを管理対象 Apple ID (Apple School Manager または Apple Business Manager を通じて組織 (学校または企業) によって管理されるアカウント) に拡張しました。つまり、学生、教師、スタッフは、管理対象 Apple ID を使用してワンクリックでアプリにログインできます。

主要内容

学校や企業におけるログインの問題は、個人のアプリの問題とは異なります。

個々のユーザーが「Apple でサインイン」を使用する場合、自分の名前を編集したり、電子メールアドレスを非表示にしたりできます。アカウントを整理することの魅力はより直接的です。アプリは誰がログインしているのかを知り、その人に適切な権限を与える必要があります。 Slack の例はその典型です。従業員が職場アカウントでログインした後、Slack は従業員の名前と電子メールアドレスに基づいてアクセスできるチャネルを決定する必要があります。 (02:15)

WWDC 2022 の変更点: Apple でサインインは、管理対象 Apple ID をサポートします。管理対象 Apple ID は組織によって所有され、Apple School Manager または Apple Business Manager を通じて管理されます。学生、教師、従業員は、このタイプのアカウントを使用して、「Apple でサインイン」をサポートするアプリにログインできます。 (01:10)

教育用アプリの場合、ログインは最初のステップにすぎません。教師が課題や通知を送信したい場合、システムは事前に生徒、教師、クラスをインポートする必要もあります。学区に数百人または数千人の生徒がいる場合、IT 管理者による手動入力では時間がかかることがあります。このために Roster API が用意されています。これにより、アプリは REST エンドポイントを通じて Apple School Manager のユーザーとクラスのデータを読み取ることができます。 (05:35)

プロセス全体は 3 つの層に分かれています。

ユーザーは管理対象 Apple ID を使用してアプリにログインします。
IT 管理者は、OAuth 2.0 を介して組織データを共有することに同意します。
アプリのバックエンドは、アクセストークンを使用して Roster API を呼び出し、ユーザーとクラスをインポートします。

このセッションには公式のコードタブスニペットはありません。以下の例は、スピーチで示される分野とプロセスに従って編成されています。これらはリクエストの構造を説明するために使用される概念的なコードであり、Apple ドキュメント内の完全なエンドポイントアドレスや SDK 署名を表すものではありません。

詳細

管理対象 Apple ID でログインするときに名前と電子メールを処理する方法

(03:12) 職場および学校で Apple でサインインを使用する場合、アプリは名前と電子メールのフィールドにアクセスできます。ただし、認可リクエストにフルネームと電子メールの範囲が含まれている場合に限ります。

このスピーチはまた、一部の学校が低学年の生徒にメールボックスを割り当てないという境界線の状況を思い出させた。この種のアカウントに遭遇した場合、アカウント作成インターフェイスには名前のみが表示され、電子メールアドレスは存在しません。 (04:18)

概念流程：成功授权后读取登录结果中的字段

userIdentifier = authorizationResult.user
fullName = authorizationResult.fullName
email = authorizationResult.email

saveOrUpdateAccount(
  stableUserID: userIdentifier,
  displayName: fullName,
  emailAddress: email
)

キーポイント:

userIdentifierこれは安定したユーザー ID であり、後で Roster API によって返されたユーザー ID と照合できます。 -fullName認可結果から;管理対象 Apple ID ログインシナリオでは、アプリは組織内の識別のためにそれを必要とします。 -email存在しない可能性があり、教育シナリオでは特に null 値を処理する必要があります。 -stableUserIDこれはアカウントに関連付けられた主キーとして使用する必要があり、電子メールアドレスは表示または補助一致に適しています。

Apple でサインインをすでに実装している場合は、管理対象 Apple ID をサポートするために追加の作業は必要ありません。このリリースにより、Apple は既存のログインエクスペリエンスを組織アカウントに拡張します。 (05:04)

開発者ポータルで組織データスコープを申請する

(08:24) Roster API へのアクセスは、開発者ポータルから始まります。開発者は、証明書、識別子、プロファイルを入力し、アカウントと組織のデータ共有でメインのアプリ ID を構成し、必要な組織のデータ共有スコープを選択します。

このリリースでは、次の 2 つのスコープが提供されます。

ユーザーアクセス: ユーザーデータにアクセスします。
クラスアクセス: クラスデータにアクセスします。

リターン URL も設定します。後続の OAuth 2.0 認証が完了すると、認証コードがこれらの URL に返されます。 (08:51)

# 概念清单：Developer Portal 配置项
Primary App ID: com.example.education-app
Organizational Data Sharing Scopes:
  - user access
  - class access
Return URLs:
  - https://example.com/apple-school-manager/callback

キーポイント:

Primary App ID組織のデータを要求するアプリをバインドします。 -user accessバックエンドが Apple School Manager のユーザー情報を読み取ることができるかどうかを決定します。 -class accessバックエンドがクラスとそのメンバーシップを読み取ることができるかどうかを決定します。 -Return URLsOAuth 2.0 認証プロセスに入ります。構成エラーにより、認証コードがサーバーに返されなくなります。

OAuth 2.0 を使用して Roster API アクセストークンを取得する

(09:47) 2 番目のステップは、IT 管理者に承認を求めることです。スピーチの例では、アプリには「Apple School Manager に接続」ボタンが用意されており、管理者はそれをクリックして OAuth 2.0 プロセスに入ります。

最初のリクエストは GET 承認エンドポイントです。リクエストには次の内容が含まれますclient_id、redirect_uri、state、response_typeそしてscopes。応答により、管理者は Apple の同意インターフェイスに移動します。 (10:16)

# 概念请求：启动授权流程
GET {authorize endpoint}?
  client_id={your-client-id}&
  redirect_uri={registered-return-url}&
  state={csrf-protection-token}&
  response_type=code&
  scope={requested-organizational-data-scopes}

キーポイント:

client_idデータアクセスを要求しているアプリを識別します。 -redirect_uri開発者ポータルで設定された戻り URL と一致する必要があります。 -state認可プロセスの変更を避けるために、コールバック中にリクエストのソースを検証するために使用されます。 -response_type=code認証コードを要求することを示します。 -scope以前に適用された組織のデータアクセススコープに対応します。

管理者が「許可」をクリックすると、Apple は認証コードを戻り URL に渡します。次に、アプリバックエンドはトークンエンドポイントに POST リクエストを送信し、アクセストークン、有効期限、およびリフレッシュトークンの認証コードを交換します。 (11:08)

# 概念请求：用授权码换取访问令牌
POST {token endpoint}
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code={authorization-code-from-return-url}&
redirect_uri={registered-return-url}&
client_id={your-client-id}

キーポイント:

authorization_code承認後に管理者からコールバックされます。 -redirect_uri登録した戻り先 URL を引き続き使用します。
応答には以下が含まれますaccess token、後で Roster API を呼び出すときに Authorization ヘッダーを置きます。
応答には次の内容も含まれますrefresh token、アクセストークンの有効期限が切れた後、新しいトークンと交換するために使用します。

リフレッシュトークンは POST トークンエンドポイントでもあります。このスピーチでは、リクエスト本文には標準の OAuth パラメータとリフレッシュトークンが含まれており、レスポンスでは新しいアクセストークンと有効期限が返されることが明確に述べられています。 (11:49)

# 概念请求：用 refresh token 更新访问令牌
POST {token endpoint}
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&
refresh_token={refresh-token}&
client_id={your-client-id}

キーポイント:

grant_type=refresh_token今回は管理者による再認証ではないことを示します。 -refresh_tokenサーバーに保存する必要があり、クライアントに公開しないでください。
新しいaccess tokenユーザーとクラスの読み取りに引き続き使用されます。

ユーザーのエンドポイントを呼び出して、学生、教師、従業員をインポートします

(12:18) 現在のリリースには、クラスリストの取得、ユーザーリストの取得、特定のクラスの取得、特定のユーザーの取得、クラス内のユーザーの取得の 5 種類の Roster API クエリが含まれています。

スピーチでは、最初にユーザーのエンドポイントが示されます。これには 3 つのクエリパラメータがあります。pageToken、limitそしてオプションのrole。pageTokenそしてlimitページングの場合、role生徒、講師、スタッフごとにフィルターします。リクエストヘッダーには、前の OAuth プロセスによって生成されたアクセストークンが含まれる必要があります。 (12:53)

# 概念请求：读取最多 10 个学生
GET {users endpoint}?limit=10&role=students
Authorization: Bearer {access-token}

キーポイント:

limit=101 つの応答で返されるユーザーの最大数を制御します。 -role=students結果を生徒に限定します。 -Authorizationヘッダーは OAuth 2.0 アクセストークンを使用します。
最初のリクエストは送信する必要はありませんpageToken。

応答は、次の内容を含む JSON ペイロードです。users、nextPageTokenそしてmoreToFollow。ユーザーオブジェクトには、givenName、familyName、電子メール、役割などの情報が含まれています。講演では、応答には安定したユーザーの一意の識別子も含まれていることを特に指摘しました。これは、ユーザーが Apple でサインインを通じて認証するときにアプリが受け取るのと同じ識別子です。 (13:14)

{
  "users": [
    {
      "id": "stable-user-identifier",
      "givenName": "Fatima",
      "familyName": "Silva",
      "email": null,
      "roles": ["student"]
    }
  ],
  "nextPageToken": "next-page-token",
  "moreToFollow": true
}

キーポイント:

users現在のページのユーザー配列です。 -idSign in with Apple のログイン結果に関連付けることができる安定したユーザー ID です。 -email多分null、アカウントモデルは電子メールに大きく依存できません。 -nextPageToken次のページング要求に使用されます。 -moreToFollowのためにtrue、手順は次のページに記載されています。

クラスエンドポイントを呼び出してクラス関係を確立します

(14:24) ユーザーをインポートした後、アプリバックエンドはクラスエンドポイントをリクエストします。学区内のクラスのリストと、クラス、生徒、教師間の関係を返します。

クラスリクエストに含まれるものpageTokenそしてlimit2 つのクエリパラメーター。リクエストヘッダーはユーザーエンドポイントと同じであり、どちらもアクセストークンを必要とします。 (14:45)

# 概念请求：读取最多 200 个班级
GET {classes endpoint}?limit=200&pageToken={next-page-token}
Authorization: Bearer {access-token}

キーポイント:

limit=200講義中の例題のスケールに対応します。 -pageTokenこのリクエストがページングインポートの処理中であることを示します。 -Authorizationヘッダーは、同じ承認プロセスから取得したアクセストークンを引き続き使用します。

応じてclassesクラス名、クラスID、教師IDのリスト、学生IDのリストが含まれます。このようにして、アプリは以前にインポートされたユーザーをクラスに関連付けることができます。 (15:10)

{
  "classes": [
    {
      "id": "class-identifier",
      "name": "Biology 101",
      "instructorIds": ["teacher-user-id"],
      "studentIds": ["student-user-id-1", "student-user-id-2"]
    }
  ]
}

キーポイント:

classes現在のページのクラス配列です。 -idローカルクラスレコードを更新または重複排除するために使用されるクラス識別子です。 -instructorIds教師のユーザー ID を参照します。 -studentIds学生のユーザー ID を参照します。
これらの ID により、アプリは「教師-クラス-生徒」のローカル関係テーブルを構築できます。

IT 管理者には 2 つのレベルのアクセス制御があります

(15:47) 組織データは組織によって管理されます。 Apple による個人サインインを使用すると、ユーザーは使用するアプリを決定できます。仕事と学校のシナリオでは、IT 管理者は、どのアプリがログインできるか、どのアプリが組織の組織データにアクセスできるかを制御する必要があります。

Apple School Manager、Apple Business Manager、および Business Essentials は、同じ制御モデルを提供します。

すべてのアプリを許可: 組織内のユーザーは、Apple でのサインインをサポートするすべてのアプリでログインできます。
特定のアプリのみを許可する: 管理者は許可されたアプリをリストに追加します。リスト外のアプリについてはエラーが表示されます。 (16:50)

組織のデータ共有にも同じパターンがあります。管理者は、Roster API を介してユーザーおよびクラス情報へのアクセスを特定のアプリのみに制限できます。これは、同意インターフェイスを超えた制御の 2 番目の層です。 (17:56)

组织侧访问控制

Sign in with Apple at Work & School:
  - Allow all apps
  - Allow only certain apps

Organizational Data Sharing:
  - Allow all apps
  - Allow only certain apps
  - IT admin consent screen

キーポイント:

ログイン権限と組織データアクセス権限は 2 つの制御セットです。
「特定のアプリのみを許可」は、使用可能なアプリを管理者が管理するリストに制限します。
名簿 API へのアクセスには管理者の同意が必要であり、組織のデータ共有アクセスモード制限の対象となります。
教育機関に接続する場合、開発者は管理者の承認とアクセス制御の指示をオンボーディングプロセスに書き込む必要があります。

重要ポイント

1. 教育アプリのスタートアップインポートをワンクリックで作成する

対処法: 管理者に [Apple School Manager に接続] をクリックしてもらい、生徒、教師、クラスを自動的にインポートしてもらいます。
実行する価値がある理由: Roster API は、学校が始まる前に数百または数千のアカウントを手動で入力するという問題を解決します。
開始方法: 最初にユーザーアクセスとクラスアクセスを申請し、次に OAuth 2.0 承認プロセスを実装し、最後にページでユーザーとクラスのエンドポイントを呼び出します。

2. ログインアカウントと名簿アカウントを安定したユーザー ID に統合します。

内容: 学生が管理対象 Apple ID を使用して初めてログインすると、Roster API で対応するユーザーレコードが自動的に検索されます。
実行する価値がある理由: このスピーチでは、Roster API によって返される安定したユーザー ID は、Apple 認証でサインインするときにアプリによって受け取られる ID と同じであると説明されています。
開始方法: アカウントテーブルは、Apple でサインインのユーザー識別子を主キーとして使用します。 Roster は、インポート時に同じ識別子を使用して名前、ロール、クラスの関係を更新します。

3. 電子メールを持たない学生向けのアカウントモデルを設計する

対処方法: 学生アカウントに電子メールアドレスを持たず、名前とクラス情報のみを表示できるようにします。
価値がある理由: Apple は、一部の学校が低学年の生徒に電子メールアドレスを割り当てないことを明確に述べています。
開始方法: 電子メールフィールドを null 可能に設定します。ログイン、インポート、通知の設定はすべて、安定したユーザー ID と組織の役割を中心としています。

4. IT 管理者向けの権限のトラブルシューティングページを作成する

操作方法: ユーザーアクセス、クラスアクセスが現在取得されているかどうか、および管理者がアプリに組織データへのアクセスを許可しているかどうかをバックグラウンドで表示します。
価値がある理由: 名簿 API アクセスは、OAuth 同意インターフェイスと組織データ共有アクセス制御の両方の影響を受けます。
開始方法: 承認が失敗した場合、トークンの更新が失敗した場合、またはインターフェイスが拒否を返した場合、エラーは「未承認」、「不十分なスコープ」、「組織側でアプリが許可されていない」の 3 つのカテゴリに分類されます。

5. クラス同期のための増分タスクを実行する

やるべきこと: スケジュールされたページでユーザーとクラスを同期し、ローカルの生徒リストと教師の関係を更新します。
価値がある理由: Roster API のレスポンシブなデザインにはページ分割されたフィールドが含まれており、バックエンドのバッチインポートや継続的な同期に適しています。
開始方法: 保存nextPageToken、同期時間とローカルにインポートされたバージョン。同期が完了するたびにオンラインクラスデータを切り替えます。

Discover Sign in with Apple at Work & School

ハイライト

主要内容

詳細

管理対象 Apple ID でログインするときに名前と電子メールを処理する方法

開発者ポータルで組織データスコープを申請する

OAuth 2.0 を使用して Roster API アクセストークンを取得する

ユーザーのエンドポイントを呼び出して、学生、教師、従業員をインポートします

クラスエンドポイントを呼び出してクラス関係を確立します

IT 管理者には 2 つのレベルのアクセス制御があります

重要ポイント

1. 教育アプリのスタートアップインポートをワンクリックで作成する

2. ログインアカウントと名簿アカウントを安定したユーザー ID に統合します。

3. 電子メールを持たない学生向けのアカウントモデルを設計する

4. IT 管理者向けの権限のトラブルシューティングページを作成する

5. クラス同期のための増分タスクを実行する

関連セッション

コメント

ハイライト

主要内容

詳細

管理対象 Apple ID でログインするときに名前と電子メールを処理する方法

開発者ポータルで組織データ スコープを申請する

OAuth 2.0 を使用して Roster API アクセス トークンを取得する

ユーザーのエンドポイントを呼び出して、学生、教師、従業員をインポートします

クラスエンドポイントを呼び出してクラス関係を確立します

IT 管理者には 2 つのレベルのアクセス制御があります

重要ポイント

1. 教育アプリのスタートアップ インポートをワンクリックで作成する

2. ログイン アカウントと名簿アカウントを安定したユーザー ID に統合します。

3. 電子メールを持たない学生向けのアカウント モデルを設計する

4. IT 管理者向けの権限のトラブルシューティング ページを作成する

5. クラス同期のための増分タスクを実行する

関連セッション

コメント

開発者ポータルで組織データスコープを申請する

OAuth 2.0 を使用して Roster API アクセストークンを取得する

1. 教育アプリのスタートアップインポートをワンクリックで作成する

2. ログインアカウントと名簿アカウントを安定したユーザー ID に統合します。

3. 電子メールを持たない学生向けのアカウントモデルを設計する

4. IT 管理者向けの権限のトラブルシューティングページを作成する