勤務先と学校でのAppleでサインインについて

♪メローなインスト ヒップホップ♪ ♪ Ashwathと申します Educationチームの エンジニアです 勤務先と学校での Appleでサインインについて 本日はお話しします このプレゼンでは今秋に 導入される 主な機能について 説明します 勤務先と学校での Appleでサインインが 何かについて 次にRoster APIと それをどのように 使うかに関する詳細 について説明します アクセス管理については IT管理者が 勤務先と学校でのAppleでサインインや Roster APIにより 組織に代わって サインインを管理する 方法について説明 したいと思います ご存知かもしれない ですが このセッションでの おさらいとして２つの 概念について説明します １つ目は Appleでサインインです Appleでサインインは ユーザーがApple IDを使用して Appにサインインするための 迅速で簡単な方法です ユーザーはタップするだけで App内に アカウントを作成できます ２つ目の概念は 管理対象Apple IDです Apple ID同様 管理対象Apple IDは デバイスをパーソナライズ するために使用されます またAppleのAppやサービスに アクセスするためにも使用されます Apple IDとは異なり 管理対象Apple IDは 組織によって 所有されており Apple School Managerや Business Managerで管理されます これらを踏まえた上で Appleでサインインが 管理対象Apple IDを サポートするよう拡張 されたことをお知らせします 素早く簡単に Appleでサインイン というエクスペリエンスに 加え 管理対象Apple IDによる 管理機能も ご活用いただけます 勤務先と学校のAppleで サインインの ユーザー体験を ご紹介するために 例を見てみることに します Slackのログイン 画面です Appleでサインインを 使用するには ユーザーは「Appleで続行」を タップするだけ Apple IDを使用すると 次のように表示されます Appleでサインインの ウェルカム画面です 管理対象Apple IDを 使用している場合は このウェルカム画面が 表示されます 勤務先と学校の Appleでサインイン画面です ウェルカム画面の違いが わかるでしょうか Appがアクセス制御を 提供とは どういうこと でしょうか？ 例を見てみます 個人のApple IDを 使用する場合 Appleでサインインして アカウント作成 画面が表示され 名前を編集したり メールを共有するか 非表示にするかを選択します これが組織の場合では 誰がログイン しているかをAppが理解 することや アクセスのレベルの把握が 重要になります この画面に表示 されている例では ユーザーは職場でSlackに サインインしています どのSlackチャネルに 参加が許可されているかを 理解するために Slackは どのユーザーがサインイン しているのかを把握する必要があるのです これがAppと共有されている 名前とメールアドレスによる 勤務先と学校での Appleでサインインを使用する場合の Slackを例にした 事例でした これはデベロッパにどのような 意味があるのでしょうか？ それは勤務先と学校での Appleでサインインを 使用すると 名前とメールフィールドにいつでも アクセスできることを意味します クライアント側のAppに 取り組んでいるデベロッパの場合 認証コントローラーを示す いくつかの サンプルコードが これです 承認に成功すると強調 表示されたステートメントに Appが受信したフルネームと メールアドレスが表示されます これは承認リクエストに フルネームとメールアドレスが 含まれていることが 前提となります Web上でAppleでサインインを サポートするデベロッパの場合 signInメソッドを使用して 認証プロセスを 開始するサンプルコードを 次に提示します 承認が成功すると サーバーはデータオブジェクトに 応答を返します データオブジェクトは 次のようになります 強調表示されたフィールドには サインイン中のユーザーの メールとフルネームが 含まれています ここでいくつか注意が 必要です このリリースでは 勤務先と学校でのApple IDでサインインは デバイスにサインした プライマリの管理対象Apple ID を使用します 表示された画面の例は デバイスの ログインフロー用でしたが Webフローもサポート されています メールアドレスがない アカウントもあります たとえば若年層の生徒には メールアドレスを 割り当てない 場合があります メールアドレスが存在 しない場合 アカウント作成画面は どう表示されるか このユーザーFatima Silvaには メールアドレスがありません そのため フルネームのみが アカウント作成画面に 表示されています Appleでサインインを 実装している場合は 管理対象Apple IDを 新たに 追加する作業は不要です まだサポートを実装 していない場合は ぜひ以下を ご覧ください WWDC2020の「Appleで サインインの―」 「最大活用」セッションと 今年の「Appleでサインイン エクスペリエンスを―」 「強化する」セッション これが勤務先と学校での Appleでサインインを すばやく簡単に 管理対象Apple IDの サインインで行う方法でした それではRoster APIについて 見ていきましょう 開始する前に次の シナリオを 考えてみることにします あなたは教育分野の デベロッパです あなたのAppは学校で 使用されています AppにAppleでサインインの サポートを実装しました 素晴らしいです！ 学生や教師にスタッフも 管理対象Apple IDで Appにログインできます Appで教師が課題や 通知を 学生たちと共有 することも 可能になります これをサポートするには IT管理者はAppに 学生 教師 クラスを 学年度が始まる前に 追加する必要があります 数百や数千の生徒がいる 学校の場合 これらを手作業で 作成するのは 時間がかかりすぎ 退屈な作業に なりかねません この問題に対処するのが Roster APIです Roster APIはユーザーや クラスなどの リソースへのプログラムによる アクセスを Apple School Manager で提供します これによりIT管理者は この情報をAppに インポートするプロセスを 自動化できます これらのリソースはRESTエンドポイント 形式で定義されています IT管理者が許可を与えた後 Appから OAuth 2.0認証を通じて このデータにアクセスできます Apple School Managerの 管理者アカウントと サイトマネージャーアカウントで どのAppがデータにアクセス できるかを管理できます このリリースの一環として 標準化された方法が 作成され Appの組織データへの アクセス要求が可能になります これを組織データ共有と 呼びます UIデザインパターンに 関しては 業界標準に準拠し デベロッパによる実装を 容易にするテクノロジーの 選択を目指しました そこでOAuth 2.0を採用して 承認フローに 組織データの共有に同意する スコープの使用と IT管理者への問い合わせが 含まれています これがその様子です 同意画面には組織の データへのアクセスを 要求しているAppに関する 情報やAppがアクセスを 要求しているデータも 表示されます さらに細かく見ると 同意画面に リクエスターに関する 情報が含まれており Apple School Managerが 提供したデータへの アクセスを要求する Appを表示しています この場合リクエスト元の AppはQuizzlerで スコープはAppがアクセス できるデータが 対象となっています この場合IT管理者が それに同意すると Quizzlerはこの組織の 全ユーザーとクラス情報に アクセスできるようになります 実装の手順は どうなっているでしょうか 最初のステップはデベロッパ ポータルに登録することで これにはスコープの 要求が含まれます 次のステップはAppとデータを 共有するために OAuth 2.0認証 フローを介して IT管理者に同意を 要求することです 最後にAppはRoster API エンドポイントにクエリを実行し データを取得します これらの各ステップを 見てみましょう スコープをリクエストするため デベロッパポータルにアクセスします の下の ページで をクリックします 次のステップで「Set up a configuration」をクリックして ドロップダウンからプライマリ App IDを選択し をクリックします 追加の構成の詳細ページの で 必要なスコープを選択 してください 現在は ユーザーアクセスとクラス アクセスの２つを提供します AppにリターンURLが設定 されていることを確認します リターンURLはOAuth 2.0 認証フローで使用されるため この手順は重要です をクリックします 最後に構成を確認します これで次のステップへの 準備が整いました 実装への２番目のステップは OAuth 2.0を介して アクセストークンを取得 することです これを詳しく見てみましょう IT管​​理者がまずAppに ログインします 次にIT管理者が Appを操作して承認フローを開始します 承認フローを開始するには たとえば「Apple School Managerに接続」という 名称のボタンをクリックします これによりOAuth 2.0標準に 準拠した一連のイベントが 開始されます 最初のステップは 承認エンドポイントへの GET API呼び出しを 実行することです このリクエストの詳細を 見てみましょう リクエストがクエリパラメータを 受理します client_idやredirect_uriに state response_typeに scopesなどです 応答はApple OAuth 同意画面への リダイレクトになり IT管​​理者にアクセスを 要求します この図ではIT管理者が 管理対象Apple IDで 認証しているという 想定です そうでない場合は 先に認証するよう 求められます IT管​​理者にはAppでの 組織データの 共有を確認するための 同意画面が 表示されます 前と同じ同意画面ですが 念のため再度表示します をクリックすると デベロッパポータルで 登録したリターンURLに 認証コードが提供されます 最後にAppのアクセストークンを 取得するために トークンエンドポイントに POSTリクエストを行います リクエストの挙動を 見てみましょう リクエスト本文は リターンURLで受信した 認証コードを含む標準の OAuthパラメータで構成されます 応答にはアクセストークンや 有効期限 そして 有効期限切れの際には 新しいトークンを作成するための 更新トークンなどが含まれます 更新トークンを使用して 新しいアクセストークンを 生成するためのリクエストの 詳細を見てみましょう リクエストの本文は更新 トークンを含む標準の OAuthパラメータで構成 されておりレスポンスには アクセストークンと 有効期限が含まれます OAuth 2.0認証フローを 正常に完了した後 Appにアクセストークンが 追加されましたのでこれを 使用して Roster APIから ユーザーとクラスの 情報を取得できます 今回のリリースの一部として Appがクエリできる ５つのエンドポイントを 導入しています これらには クラスのリスト ユーザーのリスト 特定のクラス 特定のユーザー クラス内のユーザーの取得が含まれます ユーザーとクラスの取得 方法を示すために 簡単なサンプルフローを 見ていきましょう Appサーバーはまず ユーザーエンドポイントに クエリを実行して 学生や教師 スタッフのリストを 取得します リクエストとレスポンスを 詳しく見ていきます ユーザーエンドポイントは ３つのクエリパラメーターを受理します pageTokenとlimitは ページネーションパラメータであり オプションのロールパラメータとして 学生や講師またはスタッフを 照会できます リクエストにはアクセストークンを含む 承認フローから 生成された認証 ヘッダーが必要です 応答は「users」キーを 含むJSONペイロードに ユーザーのリストがあり 「nextPageToken」 キーには 次のレコードセットを取得します 「moreToFollow」 ブールキーは クエリするレコードが 他にある場合を示します リクエストの例を 見てみましょう ここでのAPI呼び出しは 応答に最大10人の 学生がいるリストを 取得しています これは最初のAPIリクエスト であるため pageTokenクエリパラメータは 指定されていません 応答にはgivenNameや familyNameなどの 標準的なユーザー情報が 含まれますが ユーザーの一意の 識別子に ここでは焦点を当てたいと 思います これはユーザーがAppleで サインインして認証するときに Appが受理する識別子と 同じものです ユーザーのメールアドレスと 組織内でのユーザーの 役割も含まれます moreToFollowキーが trueであるため nextPageTokenは 後続のAPIリクエストで 次の学生のセットを 取得する際に クエリパラメータとして使用します ユーザーエンドポイントに クエリを 実行した後Appサーバーは クラスエンドポイントに クエリを実行し その学区にあるクラスや 学生と教師との関係などの リストを 表示できるように なります リクエストとレスポンスを 詳しく見ていきましょう get classesリクエストの 一環として リクエストは２つのクエリ パラメータを受理します pageTokenとlimit パラメータです こちらは前述のとおりです ヘッダはユーザーへのクエリ実行時と 同じものです 応答は「classes」キーが クラスのリストを保持する JSONペイロードです リクエストの例を見て みましょう このリクエストはレスポンスに 含まれる 最大200のクラスの リストを取得します APIリクエストには pageTokenパラメータもあり これは全クラスを取得中 であることを意味します 応答には名前やクラス 識別子などの 標準的なクラス情報が 含まれますが クラスの教師IDと 学生IDのリストに 着目してください Roster APIについてでした これらのエンドポイントは Apple School Managerの ユーザーとクラスに クエリを実行できる ようになりました 最後にアクセス管理について お話ししたいと思います 勤務先と学校での Appleでサインインや データ共有を利用する 組織には 管理機能を提供 することが重要です これが何を意味するのかを 詳しく説明しましょう Appleでサインインを 使用する場合 どのAppにサインインするか どうかなどの アカウント管理は ユーザー次第です 勤務先と学校でのAppleでサインインを 使用する場合はIT管理者が ユーザーに代わって アクセスを一元管理します これはIT管理者が 組織のデータの安全性と セキュリティを確保する 責任があるためです そのためIT管理者には どのユーザーが 勤務先と学校でのAppleでサインインを使用でき どのユーザーがデータ共有を使用できるかを 管理する権限が必要です アクセス管理機能は Apple School Managerや Apple Business Managerで 可能になっています 勤務先と学校での Appleでサインインには ２つのモードがあります 最初のモードは「Allow all apps」です このモードがどのように 見えるか見てみましょう ここでIT管理者はApple Business Managerにログインしています サイドバーから を選択し を 選択すると ２つのモードが提示されます 「Allow all apps」モード では組織の全ユーザーが Appleでのサインインをサポート する全Appにログイン可能です ２番目のモードは「Allow only certain apps」です このモードがどのように 見えるか見てみましょう 「Allow only certain apps」 モードでは IT管理者はAppleでのサインインを サポートする Appを検索できます ユーザーはリストに 追加されたAppでのみ Appleでサインインを 使用できます ユーザーがリストにないAppに ログインしようとすると エラーメッセージが表示されます この機能は Apple School Managerでも Apple Business Manager でも Business Essentialsの お客様でも 同じであることに 着目してください 勤務先と学校での Appleでサインインと同様 組織のデータ共有にも ２つのモードがあります それを見てみましょう 「Allow only certain apps」 モードでは IT管理者はサポートされている Appを検索してリストに追加します Roster APIにより クラスの情報にアクセスできるのは これらのAppになります これは同意画面に加えて IT管理者より どのAppが組織データに アクセスできるかを 管理する 二つ目のレイヤーとなります 勤務先と学校での Appleでサインインの リリースににより あらゆる 環境のユーザーが Appへのログインに管理対象を 含むApple IDを利用できます Appleでサインインをまだ 実装していない場合は ぜひご検討ください 教育分野にいる場合は Roster APIの採用を 強くお勧めします Roster APIのサポートを 実装するとシームレスな オンボーディング体験が IT管理者やスタッフ 教師や学生向けに 提供されます フィードバックをお待ちしております どんなフィードバックでも 提出してください 詳細を知りたい場合は 以下の動画 2020年の「Appleでサインインの 最大活用」と 今年の「Appleでサインイン エクスペリエンスを強化する」 をご覧ください ご覧いただきありがとう ございます 残りのWWDCも お楽しみください ♪