API Flashcards
API
API stands for Application Programming Interface. An API is a software intermediary that allows two applications to talk to each other. In other words, an API is the messenger that delivers your request to the provider that you’re requesting it from and then delivers the response back to you.
In OAuth 2.0, the following three parties are involved:
The user, who possesses data that is accessed through the API and wants to allow the application to access it
The application, which is to access the data through the API on the user’s behalf
The API, which controls and enables access to the user’s data
Using OAuth 2.0, it is possible for the application to access the user’s data without the disclosure of the user’s credentials to the application.
OAuth scheme
Confidential
A confidential scheme is suitable when an application is capable of maintaining the secrecy of the client secret. This is usually the case when an application runs in a browser and accesses its own server when obtaining OAuth access tokens. As such, these schemes make use of the client secret.
OAuth scheme
Public
A public scheme is suitable when an application is incapable of maintaining the secrecy of the client secret. This is usually the case when the application is native on a computer or mobile where the secret would have to be stored on the user’s device, likely inside the source code of the application. As such, these schemes do not make use of the client secret.
Why you should always use Access Tokens to secure an API
OAuth 2.0 is used to grant authorization. It enables you to authorize the Web App A to access your information from Web App B, without sharing your credentials. It was built with only authorization in mind and doesn’t include any authentication mechanisms (in other words, it doesn’t give the Authorization Server any way of verifying who the user is).
OpenID Connect builds on OAuth 2.0. It enables you, the user, to verify your identity and give some basic profile information, without sharing your credentials.
n example is a to-do application which lets you log in using your Google account and can push your to-do items, as calendar entries, to your Google Calendar. The part where you authenticate your identity is implemented via OpenID Connect, while the part where you authorize the to-do application to modify your calendar by adding entries, is implemented via OAuth 2.0.
The Third-Party Application: “Client”
The client is the application that is attempting to get access to the user’s account. It needs to get permission from the user before it can do so.
The API: “Resource Server”
The resource server is the API server used to access the user’s information.
The Authorization Server
This is the server that presents the interface where the user approves or denies the request. In smaller implementations, this may be the same server as the API server, but larger scale deployments will often build this as a separate component.
The User: “Resource Owner”
The resource owner is the person who is giving access to some portion of their account.
Creating an App
Before you can begin the OAuth process, you must first register a new app with the service. When registering a new app, you usually register basic information such as application name, website, a logo, etc. In addition, you must register a redirect URI to be used for redirecting users to for web server, browser-based, or mobile apps.
Redirect URIs
The service will only redirect users to a registered URI, which helps prevent some attacks. Any HTTP redirect URIs must be protected with TLS security, so the service will only redirect to URIs beginning with “https”. This prevents tokens from being intercepted during the authorization process. Native apps may register a redirect URI with a custom URL scheme for the application, which may look like demoapp://redirect.
Client ID and Secret
After registering your app, you will receive a client ID and a client secret. The client ID is considered public information, and is used to build login URLs, or included in Javascript source code on a page. The client secret must be kept confidential. If a deployed app cannot keep the secret confidential, such as single-page Javascript apps or native apps, then the secret is not used, and ideally the service shouldn’t issue a secret to these types of apps in the first place.
Authorization
The first step of OAuth 2 is to get authorization from the user. For browser-based or mobile apps, this is usually accomplished by displaying an interface provided by the service to the user.
OAuth 2 provides several “grant types” for different use cases. The grant types defined are:
Authorization Code for apps running on a web server, browser-based and mobile apps
Password for logging in with a username and password
Client credentials for application access
Implicit was previously recommended for clients without a secret, but has been superseded by using the Authorization Code grant with no secret.
Web Server Apps
Web server apps are the most common type of application you encounter when dealing with OAuth servers. Web apps are written in a server-side language and run on a server where the source code of the application is not available to the public. This means the application is able to use its client secret when communicating with the authorization server, which can help avoid some attack vectors.
