Imagine your team is creating an OAuth guide for clients who create APIs. You are editing the first few paragraphs of this guide, which was written by a staff engineer. You are not a subject matter expert (SME) in this topic, and are not expected to be, but must edit this section of the guide.
Goal: Make it easy for developers of APIs to understand OAuth and how it is used on your project.
Audience: Software developers who have varying levels of experience with OAuth.
- Read the following paragraphs under “OAuth Guide” and make any edits, re-writes, or corrections you feel are necessary.
- As part of your response, include the top 3-5 questions you would ask the project’s stakeholders or SMEs about this project.
Refresh tokens are approximately 40 character strings which expire once after one client.
When the client application makes a call with the bearer token in the HTTP header, you will call the token validation service with that token to ensure it is valid and contains the necessary scopes then submit the token as an authorization header in the form bearer. Checking incoming tokens is possible through calling specific endpoints and we provide the code for that here.
OAuth means open authentication. It grants third parties access to personel information without revealing passwords, resulting in less security risk. We use OAuth version two.zero for any interactions that include PHI and PII. Our platform can help you keep PII and PHI safe by defining OAuth scopes for your API’s backend, but ultimately, protecting data is up to you. Examples are your consumers will need to opt in to the write scopes for the data access they need. Sandbox data can’t contain PHI or PII. We use Okta for authentication of some third-party apps, as per exemplified with one of the health APIs. Okta is FEDRAMP-authorized and has VA authority to operate (ATO). Your API team should tell us about the scopes you will be using for your application our team will guide you through this process. See our section on bearer tokens, this is how OAuth is used.
We use OpenID Connect over OAuth 2.0 for our authorization code flow. Access depends on the API being used and the scopes for which your consumer (client) is approved. The authorization code flow grant type v2.0 uses a token that is passed from the requesting resource through the API with permission from the end user. The end user never exposes their passwords and the resource owner is able to track access grants for the purposes of easy revocation. OAuth API requests are authorized using a bearer token issued through an OpenID Connect service.
- Please do not identify yourself in your document.
- Save as a single plaintext (.txt) file.