米コロンビア大学とオランダ・デルフト工科大学の研究チームが開発した「Application of a sub–0.1-mm3 implantable mote for in vivo real-time wireless temperature sensing」は、超音波で電力供給と無線通信を行う超小型の温度センサー搭載シングルチップだ。総体積0.1立方mm以下という、塩つぶやダニに匹敵するサイズで、注射針で体内に移植し、生体信号のモニタリングを目指す。
塩つぶサイズのチップを注射で埋め込み 超音波で電力供給と無線通信実現：Innovative Tech - ITmedia NEWS
⇧ 最早SF（Science Fiction）の世界ですな。
故障とかした場合、金属探知機とかで探す感じになるんかな？
というわけで、今回も、「Google Cloud API」と「Google API」とかの話ですかね。
レッツトライ～。
認証（Authentication）って？
ちょっと、脱線して、Wikipediaさんに聞いてみた。
認証（にんしょう）とは、何かによって、対象の真正性を確認する行為を指す。
⇧ ってあるんだけど、IT系だと、
認証 (セキュリティ)
認証行為は認証対象（よって分類され、認証対象が人間である場合には相手認証（本人認証）、メッセージである場合にはメッセージ認証、時刻の場合には時刻認証と呼ぶ。 単に認証と言った場合には相手認証を指す場合が多い。
また相手認証はその方法によってCertification（サーティフィケーション）とAuthentication（オーセンティケーション）とに分類される。
Certificationは被認証者が認証場所に直接アクセスして行う認証の事で、 それに対しAuthenticationは被認証者が認証場所に直接アクセスする事無く遠隔地から電子的に受ける認証の事である
なお、Certificationであっても認証者の方は認証場所に直接アクセスするとは限らない（代わりにか認証装置が認証を行う）。
⇧ ってな感じで、電子的な「認証（Authentication）」を指すことになるかと。
認可（Authorization）って？
ちなみに、「認証（Authentication）」と言えば、漏れなく「認可（Authorization）」という概念も関係することが多いっぽいんですが、
認可（英: authorization）とは、一般的には情報セキュリティおよびコンピュータセキュリティに関わるリソースへの、とりわけアクセス制御へのアクセス権限を特定する機能である。よりフォーマルにいえば、「認可する (to authorize)」とは、アクセスポリシーを定義することである。
例えば、人事部門のスタッフは従業員の記録にアクセスする権限を与えられており、このポリシーはコンピュータシステム内のアクセス制御規則として定式化されているのが普通である。システムはそのアクセス制御規則を使って、（認証された）利用者のアクセス要求を受け入れるか拒否するかを決定する。
リソースには、個々のファイルやアイテムのデータ、プログラム、コンピュータハードウェア、コンピュータアプリケーションが提供する機能が含まれる。利用者とは例えば、コンピュータユーザー、プログラム、コンピュータ上のその他の機器を指す。
⇧ ってな感じで、最終的には「認可（Authorization）」されないと、リソースにアクセス出来なくする仕組みになってるんですかね。
悪そうな奴は大体友達、認証・認可は大体友達？
Google先生によりますと、
-
(not shown) During development, you register the application in the Google Cloud Console and obtain credentials known only by your app and Google. You also configure a consent screen. This screen is shown to users of your app to gain their consent on the scope(s) of access your app needs to their Google resources.
-
The app might also require the user to authenticate by signing in.
-
When your app needs access to Google resources, it asks Google for the scope(s) of access needed to access the resources. For example, the app might need to read metadata of the user's files in Google Drive, so it would only request a metadata read-only scope.
-
Google displays the consent screen.
-
If the user consents to the scopes of access, your app bundles the credentials and the user-approved scopes of access into a request. The request is sent to the Google Authorization Server to obtain an access token.
-
Google returns an access token with a list of scopes of access granted by the token. If the returned list of scopes is more limited than the requested scopes of access, the app disables any features limited by the token.
-
Use the access token to invoke the API and access user data.
-
(optional) If your application needs access to a Google API beyond the lifetime of a single access token, it can obtain a refresh token.
-
If additional access is needed by your app, your app asks the user to grant new scopes of access, resulting in a new request to get an access token (steps 3-6).
https://developers.google.com/workspace/guides/auth-overview?hl=ja
⇧ ってな感じで、「app（applicationの略と思われる）」とかから、「GCP（Google Cloud Platform）」に「認証（Authentication）」しに行く時に「credentials（資格情報）」をセットで送って、「GCP（Google Cloud Platform）」側で「認可（Authorization）」されたら、晴れて「GCP（Google Cloud Platform）」側のAPIが利用できるみたいな感じで、「認証・認可」はだいたいセットになるイメージなんかね？
認証・認可と認証方式の関係って？
とは言っても、
⇧ Webサイトに限ってだけでも、様々な「認証方式」があるんだけども、「認証・認可」と「認証方式」の関係って？
NECさんが「認証方式」についてまとめてくださってました。
まず初めに、3つの認証要素についてご紹介します。NIST（米国国立標準技術研究所）より発行されているNIST SP800-63 では、認証要素は性質によって「記憶(Something you know)」「所持(Something you have)」「生体情報(Something you are)」という3種類に分類・定義されています。近年広く認知されるようになった「多要素認証（Multi-factor Authenticator）」は、これら3つの要素のうち2つ以上を組み合わせることで実現されます。
⇧ となっていて、「IPA（独立行政法人 情報処理推進機構）」が「米国国立標準技術研究所 情報技術ラボラトリ コンピュータセキュリティ部門」ってとこが出してる「電子認証に関するガイドライン」ってのを翻訳してくれてるんだけど、
電子認証のモデル
[OMB 04-04]によれば、電子認証とは、電子的な手段によって情報システムに提示されるユーザ身元識別情報の信用を確立するプロセスである。システムは認証済みの身元識別情報を使用して、その個人が電子的トランザクションを実行することを認可されているかどうかを判断することができる。
⇧ ってな感じで、「電子認証」に関しては、必ず「認証・認可」はセットにするのが望ましいらしいってことなんかな？
2006年4月の資料でちょっと旧いんだけど
⇧「NIST SP800-63」ってのの翻訳が公開されてるっぽい。
⇧ まぁ、アメリカの権威ありそうな人達のお墨付きっぽいので、「認証・認可」はセットで考えちゃって良いんですかね？
Google APIとGoogle Colud APIでAPIへのアクセスに対する「認証」が異なるらしい
いろいろ脱線しましたけど、「電子認証」の世界において、「認証・認可」はセットであることがスタンダードっぽいってことは分かったんですが、「API（Application programing Interface）」に「アクセス制御（誰でも自由に使って欲しくない）」を設けたいってなった場合は、当然のことながら何かしらの「認証・認可」を設定していると思われますと。
で、この「認証（Authentication）」に関して、Googleさんが扱ってる「API（Application programing Interface）」で
の2つのグループで異なるらしいですと。
「GCP（Google Cloud Platform）」のドキュメントによると、
重要: このページでは、Google Maps Platform API といった Google Cloud APIs 以外の API の認証については説明しません。Google Maps Platform API と SDK に使用する API キーについては、Google マップのドキュメントをご覧ください。
⇧ ってな感じで、
とで、明確に「認証（Authentication）」の方法が分かれてるらしいですな。
ちなみに「Google Cloud API」と「Google API」の分類については、手前味噌で恐縮ですが、
⇧ 前回の記事でザックリとまとめてます。
上記記事を超要約すると、Googleさん曰く、「Google Cloud API」以外は全て「Google API」って括りになると言ってますね。
Google Cloud APIの認証情報って？
まぁ、「GCP（Google Cloud Platform）」のドキュメントに掲載されてるんだけど、
アプリケーション
Google Cloud APIs は、登録されたアプリケーションからのリクエストのみを受け付けます。登録されたアプリケーションは、一意に識別可能なアプリケーションで、リクエストの際に認証情報を提示します。匿名のアプリケーションからのリクエストは拒否されます。
アプリケーションの認証情報は、Google Cloud API にリクエストを送信する呼び出し側に関する必要な情報を提供します。有効な認証情報タイプには、API キー、OAuth 2.0 クライアント資格情報、サービス アカウント キーがあります。サービス アカウントは、アプリケーションの認証情報またはプリンシパル ID のいずれにも使用される場合があり、一意なものとなっています。詳細については、サービス アカウントについてをご覧ください。
⇧ ってな感じで、Google Colud APIにアクセスするための「認証情報」としては、
- API キー
- OAuth 2.0クライアント資格情報
- サービスアカウント キー
の3つの方法が用意されているらしい。
「認証情報」ってのは、おそらく、
- API key
- The credential used to request access to public data, such as data provided using the Maps API. API keys can also be used to access Google Workspace files that are shared using "Anyone on the Internet with this link can (view/edit/comment)" setting within Google Workspace sharings settings.
- OAuth 2 client ID
- The credential used to request access to user-owned data. This is the primary credential used when requesting access to data using Google Workspace APIs. This credential requires user consent.
- Client secret
- A string of characters that should only be known by your application and the authorization server. The client secret protects the user's data by only granting tokens to authorized requestors. You should never include your client secret in your app.
- Service account keys
- Used by service accounts to authorize to Google service.
- Service account
- A credential used for server-to-server interactions, such as a faceless app that runs as a process to access some data or perform some operation. Service accounts are usually used to access cloud-based data and operations. However, when used with domain delegation of authority, they can be used to access user data.
https://developers.google.com/workspace/guides/auth-overview?hl=ja
⇧ 上記に出てくる「Credential」ってことだとは思うけど。
何か、
認証ストラテジー
Google Cloud APIs では、ユーザー アカウントとサービス アカウントの認証の両方に、OAuth 2.0 プロトコルが使用されます。OAuth 2.0 を使用した認証プロセスにより、プリンシパルとアプリケーションの両方を識別します。
ほとんどの Google Cloud APIs で、API キーを使用した一般公開データへの匿名アクセスがサポートされています。ただし、API キーはアプリケーションのみを識別し、プリンシパルは識別しません。API キーを使用する場合には、プリンシパルを他の方法で認証する必要があります。
⇧ ってな感じでややこしいみたいね...
要件によって、使い分けろってことらしく、
⇧ 上記によると、
- 一般公開データ
- 限定公開データ
- 非公開データ
によって推奨される方法が異なってくるみたい。
で、上記のデータが何のことを言ってるのかの説明が一切無いんだけど、
Data type
In the context of authentication and authorization, data type refers to the entity that owns the data that your app is trying to access. There are three data types:
- Public domain data
- Data accessible by anyone, such as some Google maps data. This data is usually accessed using an API key.
- End-user data
- Data belonging to a specific end user or group, such as a specific user's Google Drive files. This data type is usually accessed using an OAuth 2 client ID or service account.
- Cloud data
- Data owned by a cloud project. This data type is usually accessed by a service account.
https://developers.google.com/workspace/guides/auth-overview?hl=ja
⇧ 上記の情報と照らし合わせて推測するに、すべて「Google」が管理してるデータってことなんかね？
頼むから、公式のドキュメントは極力曖昧さを排除して欲しいのよね...
推測でまとめると、対応関係としては、
| 日本語版ドキュメント | 英語版ドキュメント | データ管理 |
|---|---|---|
| 一般公開データ | Public domain data | |
| 限定公開データ | End-user data | |
| 非公開データ | Cloud data |
⇧ って感じになるんかな？
っていうか、日本語版と英語版で用語が変わり過ぎてて、同じことを指し示してるのか謎過ぎるんだけど...
まぁ、日本語版と英語版が上記のような対応関係であると仮定して矛盾しないという前提で整理すると、「Google Cloud API」の「認証」のイメージってのは、以下みたいな感じになるんかな？
■APIキー使うパターン
■OAuth 2.0 クライアント使うパターン
■環境提供のサービスアカウント使うパターン
■サービスアカウントキー使うパターン
⇧ 上記のイメージ図に出てくる「API」は、Googleが管理してるっぽい、
- 一般公開データ（Public domain data）
- 限定公開データ（End-user data）
- 非公開データ（Cloud data）
が管理してるんではなかろうかと推測してます。
っていうか、「非公開データ（Cloud data）」については、「Cloud project」ってはっきり明示してくれてるから、「Google Cloud API」を管理してるってことだと思うんだけど、「一般公開データ（Public domain data）」と「限定公開データ（End-user data）」については、「Google maps data（Google Maps Platformで利用できるデータと思われる）」 だったり、「user's Google Drive files」のようなデータを例として提示してるから、最早「Google Cloud API」とか関係ないやん、っていうね。
「Google Cloud API」の「認証（Authentication）」のドキュメントのはずなのにな...
Google APIの認証情報って？
Googleさんの雑な説明によると、
重要: このページでは、Google Maps Platform API といった Google Cloud APIs 以外の API の認証については説明しません。Google Maps Platform API と SDK に使用する API キーについては、Google マップのドキュメントをご覧ください。
⇧ ってあるんで、「Google Maps Platform API」と「SDK」については、「Google Cloud API」以外なので「Google API」になるはずなんで、「Google マップのドキュメント」を確認したところ、
API キーは、Google Maps Platform API と SDK を使用するアプリとプロジェクトに必要です。
⇧ とあるので、少なくとも「APIキー」による「認証（Authentication）」には対応してるらしい。
というか、「APIキー」以外の「認証（Authentication）」ができるのかは不明だし、「Google API」全般について、同様に考えて良いのかも不明なんですな...
つまり、「Google API」は「Google Cloud API」以外でGoogleが管理してるAPIのことを言ってるらしいんで、「Google Maps Platform」や「SDK」以外の「Google API」の「認証（Authentication）」方法の全量が不透明やん...。
ちなみに、公式の情報かどうか分からんのだけれど、
Google APIs
The full list of supported APIs can be found on the Google APIs Explorer. The API endpoints are automatically generated, so if the API is not in the list, it is currently not supported by this API client library.
https://googleapis.dev/nodejs/googleapis/latest/tasks/index.html#google-apis
⇧ 上記サイト様によりますと、「Google APIs Explorer」で「Google API」の全量が確認できると言っとりますね。
ただ、
EDIT 2013/Sep/13: The links below seem outdated as they do not show a complete list anymore. I found another list at https://developers.google.com/apis-explorer/#p/ containing interesting things - but this one does not seem to be complete as well.
https://stackoverflow.com/questions/6122505/complete-list-of-all-google-apis/21178816
⇧ って言ってる人もおられると...
ちなみに、
このページでは、Google Cloud プロジェクトで有効になっている、または使用可能な API やサービスを一覧表示する方法について説明します。利用可能または有効になっている API やサービスの一覧には、Pub/Sub などの公開されている Google Cloud サービスと、Cloud Endpoints を使用して作成されたサービスのような、個人的に共有されている API やサービスの両方が含まれている可能性があります。公開 API と非公開 API サービスの相違について詳しくは、一般公開サービスと非公開サービスをご覧ください。
https://cloud.google.com/service-usage/docs/list-services#curl_1
⇧ ってな感じで、「Google Cloud API」の一覧を確認する方法はあるらしい、ただ「GCP（Google Cloud Platform）」の利用が必須みたいね...
なので、「GCP（Google Cloud Platform）」を利用して、「Google Cloud API」の一覧を確認して、そこで確認できないものについては「Google API」って考えるしかないらしい、つまり「Google API」の全量を把握するのは、Googleの中の人以外はほぼ不可能ってことになるんですかね...
いつも思うのは、サービスを提供する側って、使って欲しいと思ってないってことなんですかね？
普通、使って欲しいと思うのなら、説明をしっかりしようと意識するとは思うんだけど...
毎回モヤモヤ感が半端ない...
公式のドキュメントで「Google Cloud API」と「Google API」って分類してるんならさ、ちゃんと「API」の「認証（Authentication）」についてのドキュメントは、 「Google Cloud API」だけじゃなく、「Google API」についても全量を整理して欲しいですな...
今回はこのへんで。
