「認可」とは何でしょうか。「認証」と一字違いですし、混同しやすいことも多いようです。
英語でも、認証は、"Authentication"、認可は、"Authorization"で、似ています。ただし、その意味は異なりますので、ここではっきり理解したいところです。
　
今回もまずは簡単に一文で表現してみましょう。
認可とは、「"特定の条件"に対して、"特定の何か"へのアクセスを許すこと」です。 ここで、「特定の条件」というのは、例えば「ユーザAさんが、社内のLANを使ってアクセスする場合」というような条件です。
また、「特定の何か」というのは、広義では、「管理対象のリソース」ですが、IDaaSの文脈で言えば、「特定のサービス」と言い換えた方がわかりやすいかも知れません。IDaaSと連携するサービスで、例えば、G SuiteのGmailなどです。
つまり、

• ユーザAさんは、社内のLANからのアクセスに限り、Gmailを利用できる。
• ユーザBさんは、特定の端末からのアクセスに限り、インターネット経由で、Google Driveを利用できる。

というような、利用の制限をすることができるという機能です。

このように、「認可」されるべき主体は、「認証」によって明らかにされた「特定のユーザ」ということになります。認可されるべき条件は、「誰か」以外の要素もありますが、あくまでも、「誰に対する認可なのか」ということを中心に考えるべきでしょう。その点で、「認可」は、「認証」に依存している機能で、認可の前段階で、認証が済んでいることが求められます。

また、IDaaSでは、特定のユーザという個人ではなく、特定のグループや組織に対する認可もできるようになっています。IDaaSは、第二回の記事で書いたとおり、Identityに関する情報を保持しています。どのユーザがどのグループや組織に属しているということを知っているので、個人に対してではなく、グループに対して認可することで、管理が容易になります。
例えば、

• 経理部は、社内のLANからのアクセスに限り、Gmailを利用できる。
• 営業部は、特定の端末からのアクセスに限り、インターネット経由で、Google Driveを利用できる。

というような認可のルールを作ることが出来ます。
経理部は社外からは仕事をしないので、会社の中でだけメールが読めれば良く、営業部は社用端末で、社外からも資料にアクセスするというような仕事内容に合わせたルールを柔軟に設定することができます。このような組織やグループに対して認可する機能がない場合は、人の出入りが多いような会社では、管理が煩雑になり、最悪な場合には、意図しない人に適切でないサービスを許可してしまうなどのセキュリティ事故を招くことになります。

アクセス制御については、前回の記事でも触れました。認証というレベルでも、アクセスの制御をすることが可能ですが、認証を経て、利用者が誰なのかということがわかってから、さらにその他の条件で、対象のサービスに対するアクセスを制御する方がより細かく柔軟な制御が可能になります。
前述の例のように、「特定の条件」の組み立ての要素が多いほど、よりきめ細やかなアクセス制御が可能と言えます。 IDaaSは、その名称を聞いただけでは、「セキュリティ」に寄与するような機能とはやや遠いように思われますが、「認証」および「認可」の機能で実現するアクセス制御は、IDaaSで享受できる大きなメリットです。

また、IDaaSが実現する機能に、シングルサインオン（SSO）があります。この機能は後の記事でより掘り下げる予定ですが、「認可」の視点から、軽く触れておきます。
SSOは、一度認証を通れば、IDaaSが連携するサービス群に対して、個別にログインせずに、利用できるようになるという利便性のための仕組みです。ここで、利用者はSSOできるサービス群に対して、「認可」されている必要があります。つまり、SSOして良いのかということを定義する基礎的な機能として、「認可」が利用されていることになります。SSOは、実際にはIDaaS側や、サービス側でももっと多くの基礎的な機能を組み合わせることで実現していますが、「認可」も重要な役割を担っています。

前々回の「保存」、前回の「認証」、そして、今回「認可」は、それ単体では、単純な機能ですが、IDaaSを使うことで、得られるメリットを形作るための「基礎的な機能」と言えます。より高次な機能である「アクセス制御」や「SSO」を実現するための部品という見方もできると思います。 次回は、まだ部品とも言える機能ですが、やや聞き慣れない「プロビジョニング」という機能について掘り下げます。