認證、授權與常見的認證方式

認證與授權

  • Authentication: Refers to proving correct identity
  • Authorization: Refers to allowing a certain action

常見的認證方式有下列幾項:

HTTP Authentication Schemes (Basic & Bearer)

常見的HTTP認證被定義於:RFC-7235 Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry,較常見的有:

Basic Authentication

目前此種認證方式因為其弱點(inherent security vulnerabilities)而被建議不要使用。採用者種認證方式的使用者會將帳號密碼採用Base64編碼置於HTTP Request中

Authorization: Basic bG9sOnNlY3VyZQ==
Bearer Authentication

通常被認為是OAuth 2.0的一部分,可參考RFC-6750

Authorization: Bearer <token>
API Key

最常被使用在 REST API 認證中,被設計出用來改進HTTP Basic Authentication方法,但也常被認為是不安全的認證。因為很多API Key常常會出現在URL網址中,因此,API KEY 要盡量避免用於query string,當作參數傳遞。

Authorization: Apikey 1234567890abcdef

OAuth

OAuth 2.0 是最適合被用來認證個人帳密及取得資訊使用。

  • access token: sent like an API key, it allows the application to access a user’s data; optionally, access tokens can expire.
  • refresh token: optionally part of an OAuth flow, refresh tokens retrieve a new access token if they have expired. OAuth2 combines Authentication and Authorization to allow more sophisticated scope and validity control.

四種認證方式:

  • Authorization code – The most common flow, mostly used for server-side and mobile web applications. This flow is similar to how users sign up into a web application using their Facebook or Google account.
  • Implicit – This flow requires the client to retrieve an access token directly. It is useful in cases when the user’s credentials cannot be stored in the client code because they can be easily accessed by the third party. It is suitable for web, desktop, and mobile applications that do not include any server component.
  • Resource owner password – Requires logging in with a username and password. Since in that case, the credentials will be a part of the request, this flow is suitable only for trusted clients (for example, official applications released by the API provider).
  • Client Credentials – Intended for the server-to-server authentication, this flow describes an approach when the client application acts on its own behalf rather than on behalf of any individual user. In most scenarios, this flow provides the means to allow users to specify their credentials in the client application, so it can access the resources under the client’s control.

OpenID

OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, which allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner. 

OpenID Connect specifies a RESTful HTTP API, using JSON as a data format. User identity information is encoded in a secure JSON Web Token (JWT), called ID token.

OpenAPI Security Schemes

  • Basic API Authentication
  • OAuth1.0 (Digest Scheme)
  • OAuth2 (Bearer Token Scheme)
  • OpenID Connect Discovery

結論

目前公認較安全的認證方式為OAuth 2.0,OpenID也有後來居上的態勢。

參考資料: