Researcher Auth Service (RAS) Project Service Offerings

Getting Started

This document explains the authentication, authorization, and logging services available to NIH Institutes and Centers and extramural systems desiring information about users requesting access to NIH’s open and controlled data assets and repositories through the NIH Researcher Auth Service (RAS).

The intended audience for this document is technical developers and leaders responsible for design and implementation of the integrations with the RAS APIs.

Prerequisites

The following are the recommended prerequisites to using this document:

Available API endpoints

The following table illustrates the OAuth 2.0 and Open ID Connect 1.0 endpoints which are available for testing:

API Endpoint Purpose Reference
/auth/oauth/v2/authorize Initiate process to allow resource owner to permit client access OAuth 2.0
/auth/oauth/v2/authorize/login Prompts resource owner to login before permitting client access OAuth 2.0
/auth/oauth/v2/authorize/consent Prompts resource owner to allow or deny client access OAuth 2.0
/auth/oauth/v2/token Processes the token issuance step OAuth 2.0
/auth/oauth/v2/token/revoke Revokes an issued token OAuth 2.0
/openid/connect/v1/userinfo
(deprecated - date 3/31/2022)		 If presented with a valid access token, returns claims about the requested user OIDC 1.0, GA4GH Passports Spec, GA4GH AAI OIDC RFC.
/openid/connect/v1.1/userinfo If presented with a valid access token, returns claims about the requested user OIDC 1.0, GA4GH Passports Spec, GA4GH AAI OIDC RFC.
/connect/session/logout Terminates the current Open ID active session OIDC 1.0
/openid/connect/jwks.json Used to publish the JWK set public keys used by clients to validate a JSON Web token (JWT). OIDC 1.0
/.well-known/openid-configuration Used to retrieve metadata about the RAS OpenID Connect configuration. OIDC 1.0

Available Identity Providers (IdPs)


Note: Please review Identity Assurance Level (IAL) and Authenticator Assurance Level (AAL) as defined by the National Institute of Standards and Technology in NIST Special Publication 800-63 as these concepts are essential to understand the requirements being met by the IDPs below

  • NIH Active Directory
    • Identity Assurance Level (IAL) 3 identity that is authenticated at Authenticator Assurance Level (AAL) 3 when using NIH issued PIV card. First name, last name and email address are available. As of May 6th, 2024, RAS also makes Institute/Center information available upon successful user authentication when using NIH AD.
  • eRA Commons with user roles and affiliations (IAL1)
    • IAL1 identity that is authenticated at AAL1. First name, last name, email address, and role information are available.
  • Login.gov
    • Options to require IAL 1 and 2 are available along with various multi factor authentication options. Email address is available at IAL1; first and last name at IAL2.
  • ID.me
    • More than 70 million individuals already have IAL2/AAL2 credentials, meaning many users may arrive at your flow with a verified identity. IAL1/AAL2 or IAL2/AAL2 verification is required, along with one of several multi-factor authentication (MFA) options. If a user has previously verified their identity at IAL2/AAL2 through another organization, they do not need to verify again—they simply need to consent to share their verified identity information with NIH.
  • InCommon Federation
    • Individuals from U.S. and international research institutions that participate in this federation (check here for participating institutions) can use their home institution credentials. Options for various Identity Assurance Profiles (IAP) are available with multi-factor authentication (MFA). First name, last name, email address, and organization are available.

    Partner Systems should understand the levels of assurance defined in the REFEDS Assurance Framework v2 Identity Assurance Profile (IAP) specification and the NIST SP800-63-3 Identity Assurance Level (IAL) standard when determining authentication requirements. NIH accepts IAP High in lieu of IAL2.
  • Google for Authentication Only
    • Google can be configured to provide Authentication only for RAS end-users. Email address, first name and last name are available at IAL1.

Requests for RAS to integrate additional IdPs should be included with system integration requirements and will be considered by the project team.


Note on Authentication Assurance Levels (AAL) and Multi-Factor Authentication (MFA):

For login with IDPs other than Google and eRA Commons, RAS enforces MFA at a minimum of Authentication Assurance Level (AAL) 2. If an AAL of less than 2 is detected, the user will be directed to a step-up page to reauthenticate before authorization details can be forwarded to the partner system.


Note on Identity Assurance Levels (IAL) and Identity Proofing:


For Partner Systems that are NIH Controlled Access Data Repositories (CADRs), RAS must be configured to require their users to register with a RAS-approved Identity Provider (IdP) at Identity Assurance Level (IAL) 2 or higher before granting system access. As part of this configuration, RAS can detect a user has not met the required identity assurance level during authentication, and if detected, the user is prompted to upgrade their identity proofing level.


Compliance and Security Requirements

The National Institutes of Health’s (NIH) Office of Data Science Strategy (ODSS) is committed to continuous improvement of partner engagement with the Researcher Auth Service (RAS). The purpose of the Compliance and Security requirements is to ensure that all RAS partners understand and are applying the appropriate best practice security requirements approved by the NIH Chief Information Security Officer.

Please refer to this site regularly for updates to frequently asked questions (FAQs) from RAS Partner Systems. (Last updated: April 6, 2022)

  1. Which security and other standards frameworks does RAS follow?
    1. RAS is part of the NIH CIT IAM General Support System (GSS) which is a Federal Information Security Management Act (FISMA) High system. As such, RAS will adhere to NIST (National Institute of Standards and Technology) 800-53 and 800-57 guidelines pertaining to configuration management, least privilege, and cryptographic key establishment & management.
    2. For authorization processing, RAS complies with the Global Alliance for Genomics and Health (GA4GH) approved specifications for packaging “passport claims” and “passport visas” as detailed in the GA4GH Passports and Authentication and Authorization Infrastructure specifications.
  2. Will all our system users have to log in with RAS?
    1. Yes – When a Partner System has been onboarded into RAS to enable access NIH controlled access data, their users will be required to log-in via RAS with a supported identity provider to access their data.
  3. Can we link user accounts from RAS with non-RAS accounts?
    1. No – Partner side linking of non-RAS IdP accounts to RAS accounts is prohibited. To maintain authentication method and ID proofing security controls, RAS tokens currently can only be released based upon RAS authentication.
  4. Can we repackage RAS visas into a non-RAS passport, and use those passports for access to NIH data?
    1. No - RAS Visas must not be repackaged into a Passport issued by any other broker. The integrity of the RAS passport, and the ability to validate passport-level claims and visa tokens, are critical aspects of the overall RAS security model.
  5. How can we trust an external system that requests data using a RAS passport?
    1. Trust is established with NIH Approved third party Certificate Authority (CA) certifications that facilitate client/server mutual authentication to securely exchange the RAS passport.
  6. How do we know that we’ve been presented with a real RAS passport?
    1. A RAS Clearinghouse verifies the Passport being presented is a real RAS Passport by verifying that the issuer is NIH and that it has been signed by NIH RAS. Currently, existing and new Partners create their own RAS Clearinghouse using NIH-supplied instructions in the Interconnection Security Agreement (ISA). These RAS Clearinghouses will be subject to testing and ongoing inspection to ensure NIH contractual compliance.
  7. Can international users verify their identity?
    1. Yes. Users can verify if they live outside of the United States and have a Social Security number, Individual Taxpayer Identification Number (ITIN), or non-U.S. passport. For step-by-step instructions, visit the ID.me Help Center.

Testing Considerations

Development

To engage in development testing with NIH RAS, the following steps must be adhered to:

  1. When using the authorize request, the scope parameter must include “openid” in order to get an ID Token returned.
  2. ID Tokens returned from RAS should be checked to ensure secure delivery and validity.
  3. Profile, phone, and email information should be retrieved via the “userinfo” request.
  4. To comply with GA4GH, only the following signing algorithm will be supported: RS256.
  5. Only the following encryption algorithm will be supported: RSA.

Production

The following steps should have been completed prior to promoting an integration with RAS into Production:

  1. ServiceNow or GitHub request was raised for the integration in a non-production environment.
  2. Integration was successfully implemented in the lower environment.
  3. End-to-end testing was successfully completed.
  4. Documented test results or summary was provided to the IAM OIDC team showing successful Integration and User Acceptance Testing.
  5. A ServiceNow or GitHub request was raised for the Production deployment.
  6. Production deployment planning activities (date/time of rollout, shakeout activities and responsibilities and production support plan) were discussed and agreed to with the IAM OIDC team at least a week prior to the planned go-live date.
Frequently Asked Questions (FAQs)
What is a Controlled Access Data Repository (CADR)? A Controlled Access Data Repository (CADR) is a secure system used to store and manage sensitive research data. Access to data in a CADR is restricted to authorized users who meet specific eligibility, data use, and compliance requirements.
Why are CADRs used? CADRs are used to protect sensitive data, such as human subjects' data, genomic data, or other controlled information, while still enabling qualified researchers to access data for approved research purposes.
What is the Researcher Authentication Service (RAS)? The Researcher Authentication Service (RAS) is the NIH enterprise federated identity and authentication service for controlled-access data. It enforces a researcher's identity assurance requirements and institutional affiliation.

RAS acts as an identity broker, redirecting users to a trusted Identity Provider (IdP), such as a university or Login.gov, to authenticate. Once verified, RAS passes the authenticated identity to provide researchers with a seamless single sign-on (SSO) across participating data repositories, improving both security and user experience.
How does RAS work with CADRs and why is it required? RAS enables secure login to CADRs by redirecting researchers to a trusted IdP to authenticate (confirm their identity). Once verified, RAS passes the authenticated identity to the CADR. The CADR then handles authorization, determining what data the researcher is allowed to access based on approved permissions.

RAS is required to ensure that only verified and accountable researchers can access controlled data. It supports strong identity assurance, auditability, and compliance with federal and institutional data security policies.
How long will it take to integrate with RAS? The current onboarding timeline is approximately 8 to 10 weeks to reach production. CADR owners are encouraged to begin communicating IAL2 requirements to their user community early in the process.

Reference materials are available to support communication with users, including templates and guidance here.
What is Identity Assurance Level (IAL)? Identity Assurance Level (IAL) is a NIST standard and refers to the degree of confidence that a user's identity has been verified, as defined by NIST 800-63-3.

RAS supports three levels:
  • IAL1 (Low Assurance): Self-asserted identity with no verification
  • IAL2 (Medium Assurance): Verified identity using trusted proofing methods
  • IAL3 (High Assurance): Highest level of verification, including strong identity proofing (e.g., biometrics)
What is an InCommon Identity Assurance Profile (IAP)? The Identity Assurance Profile (IAP) standard is part of the REFEDS Assurance Framework (RAF), which is used across federations such as InCommon to indicate the level of identity assurance associated with an authenticated user.

Within InCommon, participating identity providers may assert REFEDS IAP signals (e.g., IAP Low, Medium or IAP High) to communicate the level of identity proofing performed.
What IAL is required to access CADRs? Users of CADRs are required to be identity proofed at a minimum of NIST IAL2 to access controlled data. Anything lower is insufficient to access CADRs.

Users authenticating using the InCommon Federation to access CADRs are required to be identity proofed at REFEDS IAP High which NIH has assessed and accepts as comparable to NIST IAL2.
Why is IAL2 (or IAP High) required for CADR access? A minimum of NIST IAL2 or REFEDS IAP High identity assurance levels are required to be compliant with NIH's stronger identity proofing standards when accessing CADRs. This ensures that a user's identity has been verified against real-world evidence. This level of assurance is required to protect sensitive research data and meet federal security and compliance requirements.
What is an Identity Provider (IdP)? An Identity Provider (IdP) is a trusted organization that verifies your identity and authenticates you when you sign in. This is typically your institution or a government-approved provider.
How do I meet IAL2 or IAP High requirements? To meet IAL2 or IAP High requirements, you must complete identity verification through a supported Identity Provider such as Login.gov and ID.me. The verification process may include:
  • Providing identifying information
  • Verifying official documents
  • Completing remote or in-person identity proofing
What IdPs are accepted for CADR access? CADRs accept IAL2+ compliant Identity Providers, including:
  • Login.gov
  • ID.me
  • NIH PIV Card
  • InCommon federation (REFEDS IAP High certified institutions)
Where can we learn more about the identity proofing processes for each IdP? Each identity provider offers guidance on their identity proofing processes. The following resources provide more information:
Identity proofing methods vary by institution and geographic location of the researcher; please consult your home institution for details.
How do I link my Login.gov or ID.me account to eRA Commons? If linking is required, you will be prompted during sign-in to link your IAL2 account (Login.gov or ID.me) with your eRA Commons account.

To complete the process:
  • Sign in using your Login.gov or ID.me account
  • When prompted, proceed to link your account
  • You will be redirected to the eRA Commons login page
  • Sign in with your eRA credentials
  • Once completed, your identities will be linked

If the linking process is not completed within approximately 5 minutes, you will need to restart the process by logging in again.
Can ID.me and Login.gov identity proof my users from countries around the world? International users may verify their identity with:
  • Login.gov if they have a valid U.S. state-issued ID, Social Security number (SSN), and U.S. address
  • ID.me if they have an Individual Taxpayer Identification Number (ITIN) or a non-U.S. passport

Availability and methods may vary, so users should review the identity provider's guidance for the most current options.
I already have an IdP (like Keycloak), how will that integrate with RAS? RAS serves as NIH's enterprise identity broker for authentication to CADRs. This means CADRs must rely on RAS for user authentication and cannot use a separate identity provider (such as Keycloak) for direct login.

However, existing systems like Keycloak may still be used within your environment for authorization or role management, depending on your architecture.
Who can access data in a CADR? Only authorized researchers who have an approved data access request, have completed required training, and meet institutional and regulatory requirements may access data stored in a CADR.
Do I need a specific type of account to use RAS? Yes. You must have an account from an institution or organization that participates in the RAS federation and meets the required identity assurance levels. In addition, your account must be associated with an organizational (institutional) email address to verify your affiliation and support access to controlled data.
Is RAS responsible for approving data access? No. RAS only authenticates the identity of researchers. Data access approval decisions are made by the data repository or data access committee.
After integrating with RAS, can we still use our eRA credentials to access a CADR? Users will not be able to sign into a CADR using their eRA credentials directly. However, they can link their eRA account to an IAL2-compliant identity provider (such as Login.gov or ID.me) to retrieve their eRA roles and permissions.
What responsibilities do researchers have when using CADRs? Researchers must comply with approved data use agreements, protect data confidentiality, follow security requirements, and report any data incidents or breaches as required.
Can I share my access or credentials? No. Access is granted to individuals and may not be shared. Credential sharing is a violation of policy and may result in loss of access.
Who oversees compliance? Compliance oversight may involve NIH Data Access Committees, repository operators, and relevant HHS or NIH security, privacy, and research compliance offices. This includes compliance with data use agreements, privacy and confidentiality requirements, federal information security policies, and applicable regulations governing controlled-access research data.
Additional Support
Where can I get help or support? Please report any issues you encounter to the RAS CADR Team at nihrasteam@mail.nih.gov

Additional resources are available to assist both users and implementers:
We don't have controlled access data but we are mandated to use RAS, what should we do? You should confirm with the Office of Science Policy (OSP) whether CADR requirements apply. If integration with RAS is required, contact the RAS CADR Team to begin the onboarding process.

Appendix A. OIDC Token Exchange Samples

Note: This is a subset of samples available through the RAS endpoints. A full set of samples are available in the NIH RAS Partner Developer Guide.

Authentication Response Sample

{
  "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImRlZmF1bHRfc3NsX2tleSJ9.ew0KICAiaXNzIjogImh0dHBzOi8vZmVkZXJhdGlvbmRldi5uaWguZ292OjQ0MyIsDQogICJpYXQiOjE1NzYxNzYwNzEsDQogICJhdWQiOiI1ZWVkODY4ZS03YWQwLTQxNzItODhmMi03MDRiY2Y3OGI2MWUiLA0KICAiZXhwIjoxNTc2MTc5NjcxLA0KICAianRpIjoiNDA1NWE4Y2ItNTVlNC00YmQyLTkyYWEtYjVhOWM5YWM0NjEyIiwNCiAgInRva2VuX2RldGFpbHMiOiB7DQogICAgInNjb3BlIjoicGhvbmUgZW1haWwgYWRkcmVzcyBwcm9maWxlIG9wZW5pZCIsDQogICAgImV4cGlyZXNfaW4iOjM2MDAsDQogICAgInRva2VuX3R5cGUiOiJCZWFyZXIiLA0KICAgICJwcmVmZXJyZWRfdXNlcm5hbWUiOiJyb2JpbnNvbmpld0BuaWguZ292IiwNCiAgICAibmFtZSIgOiAiQWJoaXNoZWsgQmFqcGFpIiwNCiAgICAiZW1haWwiIDogImFiLmJhanBhaUBuaWguZ292IiwNCiAgICAiVUlEIiA6ICJhYi5iYWpwYWlAbmloLmdvdiINCiAgfQ0KfQ.LNhOk4cW16VP48PZqa5vV23KcLl9mCzsQdmtZzB3XFLSlj7kEaJNde07Bu4pqnrWuLMTilIjwZIy1P389aZwDCfVHUlLf9sBUAZSID8ug-Pdgnso7gBaALhSrztGGQ7GYsg4UAKs9XNDEgXaHJ5yCbxxOFusNTFX3LMwYMkKAgMPpYyexAZMpB__AAPfqqR4FWN6-OWs7vJhBbRcfNFAS_7WrJ-bQtc4i1HYFfowOrfooJ0Q3e9JcQJvVpuln_0eB_y9_KlMsv0LkWNbKbPM26dz5nvled1s6i6U8BxafYlz7F-1p8aF31P4AVz3iPDbW6dxbWaw79aWwBHLaVEg",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "63cba819-aa3d-4492-a02e-a48ca3040xxx",
  "scope": "phone email address profile openid",
  "id_token": "eyH0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImRlZmF1bHRfc3NsX2tleSJ9.ewogInNYiI6ICJoek8zRGtKLTNDSXVqSTFob3F1RU5ITEtiRUJVNkxXLW9VR0hMWXBwN2M0IiwKICJhdWQiOiAiNWVlZDg2OGUtN2FkMC00MTcyLTg4ZjItNzA0YmNmNzhiNjFlIiwKICJjX2hhc2giOiAiZlhLSnlfTzB1bk NEeHo4MXgyUGNZZyIsCiAiYWiMbCgyPl0-JLN62_UJTh0uZFP2xNlo0fqc5wYxHS7YoGU26xakrcMGRXJZpbZHSwofZ5x5K7h3_dMM5y_KEDoiytlG8mQFjD6w3bCmQKsiMfvDVC0rRzBrVbZjzk7r3daJFbw6S0gxt3BObNmfmBHXlEQBH0QY2lVN7AupmFOpOLgmRcqQpRKaAeXS6fwPHRVPFl4_g6_hSq-A0s7ZZx7O1u7SlFblEIvTUpZF8QIACvhfNroPmFqZYpldtMLmHN5ZO3eRsIfmRm6EeVnXbucyihRhcJTapX3--ypl5mStfGRiyAw7qEa3ju1tK58Bje8w",
  "id_token_type": "urn:ietf:params:oauth:grant-type:jwt-bearer"
}

ID Token Payload Sample

{
  "sub": "BPO3DkJ-3CIujI1hoquENHLKbEBU6YY-oUGHLYpp7xx",
  "aud": "6ffd868e-7ad0-4172-88f2-704bcf78b6ff",
  "c_hash": "fYMJy_O0unCDxz81x2PcYg",
  "acr": "0",
  "azp": "5eed868f-7ad0-4172-88f2-704bcf78b6ff",
  "auth_time": 1276176058,
  "iss": "https://fqdn.gov",
  "exp": 1226262466,
  "iat": 1226176072,
  "nonce": "000000000"
}

Version 1.1 UserInfo Response Sample with Encoded Passport

(Scopes: openid email profile federated_identities ga4gh_passport_v1) 
{
	"sub": "ROcDp0JG4LxZrU7bjBjyzXO_jiv-AWYDrkKDPitt-Xo",
	"name": "JohnDoe",
	"preferred_username": "Doej_pi@era.nih.gov",
	"userid": "Doej_pi",
	"email": "John.Doe@nih.gov",
	"federated_identities": {
		"default_identity": "Doej_pi@era.nih.gov",
		"authenticated_identity": "Doej_pi@era.nih.gov",
		"sources": [{
			"login.gov": {
				"identity_username": "03de52c8-194c-4eae-915f-1de3a34206f0@login.gov",
				"ial": 1
			},
			"era": {
				"identity_username": "Doej_pi@era.nih.gov",
				"ial": 1
			}
		}],
		"identities": [{
			"login.gov": {
				"userid": "03de52c8-194c-4eae-915f-1de3a34206f0",
				"mail": "John.Doe@nih.gov"
			},
			"era": {
				"mail": "John.Doe@nih.gov",
				"firstname": "John",
				"lastname": "Doe",
				"userid": "Doej_pi"
			}
		}]
	},
	"txn": "68f70cf32eed4e64.96ae81a37b343b9a",
	"passport_jwt_v11": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImRlZmF1bHRfc3NsX2tleSJ9.ew0KInN1YiI6IlJPY0RwMEpHNEx4WnJVN2JqQmp5elhPX2ppdi1BV1lEcmtLRFBpdHQtWG8iLA0KImp0aSI6Ijc1YzRmNmZkLTc0NmUtNGEyMi1iZjBhLTM0NTg3ZGNiZDhmOCIsDQoic2NvcGUiOiJvcGVuaWQgZ2E0Z2hfcGFzc3BvcnRfdjEiLA0KInR4biI6IjY4ZjcwY2YzMmVlZDRlNjQuOTZhZTgxYTM3YjM0M2I5YSIsDQoiaXNzIjogImh0dHBzOi8vc3Rzc3RnLm5paC5nb3YiLCAKImlhdCI6IDE2MjkyMzA1NjQsCiJleHAiOiAxNjI5MjczNzY0LAoiZ2E0Z2hfcGFzc3BvcnRfdjEiIDogWyJldzBLSUNBaWRIbHdJam9nSWtwWFZDSXNEUW9nSUNKaGJHY2lPaUFpVWxNeU5UWWlMQTBLSUNBaWEybGtJam9nSW1SbFptRjFiSFJmYzNOc1gydGxlU0lOQ24wLmV3MEtJQ0FpYVhOeklqb2dJbWgwZEhCek9pOHZjM1J6YzNSbkxtNXBhQzVuYjNZaUxBMEtJQ0FpYzNWaUlqb2dJbEpQWTBSd01FcEhORXg0V25KVk4ySnFRbXA1ZWxoUFgycHBkaTFCVjFsRWNtdExSRkJwZEhRdFdHOGlMQ0FOQ2lBZ0ltbGhkQ0k2SURFMk1qa3lNekExTmpRc0RRb2dJQ0psZUhBaU9pQXhOakk1TWpjek56WTBMQTBLSUNBaWMyTnZjR1VpT2lBaWIzQmxibWxrSUdkaE5HZG9YM0JoYzNOd2IzSjBYM1l4SWl3TkNpQWdJbXAwYVNJNklDSXhNMlkyT1dNMk5pMDBOMlExTFRRNE9EQXRZak15TVMxaVlqQTRORFUwWW1FellUY2lMQTBLSUNBaWRIaHVJam9nSWpZNFpqY3wZMll6TW1WbFpEUmxOalF1T1RaaFpUZ3hZVE0zWWpNME0ySTVZU0lzRFFvZ0lDSm5ZVFJuYUY5MmFYTmhYM1l4SWpvZ2V5QU5DaUFnSUNBZ0luUjVjR1VpT2lBaWFIUjBjSE02THk5eVlYTXVibWxvTG1kdmRpOTJhWE5oY3k5Mk1TNHhJaXdnRFFvZ0lDQWdJQ0poYzNObGNuUmxaQ0k2SURFMk1qa3lNekExTmpRc0RRb2dJQ0FnSUNKMllXeDFaU0k2SUNKb2RIUndjem92TDNOMGMzTjBaeTV1YVdndVoyOTJMM0JoYzNOd2IzSjBMMlJpWjJGd0wzWXhMakVpTEEwS0lDQWdJQ0FpYzI5MWNtTmxJam9nSW1oMGRIQnpPaTh2Ym1OaWFTNXViRzB1Ym1sb0xtZHZkaTluWVhBaUxBMEtJQ0FnSUNBaVlua2lPaUFpWkdGakluMHNEUW9nSUNBZ0lDSnlZWE5mWkdKbllYQmZjR1Z5YldsemMybHZibk1pT2lCYkRRb2dJQ0FnSUNBZ0lDQU5DaUFnSUNBZ1hTQU5DbjAubHBFUG1pdVBzX0tpcURfazlfTUZoaXFWc3FnZnlEMVFIeHRVU2gwMWZFMVlGX2dTamR6N2pjTGVROVpzb09rT01wbktJcFowV0tsSmVrOFFEaE16VFpxRTJHektXRXdrUGl1NklSMTdxWDN0M2ZUVkw3TTBRTzNMVHZPNlg5NVNyVGVBU19ROHNyNzdEa2IxOVhmdDctS3NzLWFvcGlMVWFRRjJVZVBmNHhTTGxRWTZPaXlhSkJhakN3TnhpcUdhNTFvOE5KY1ppVGZ3YldseVJsT2ZSNzFhU010b0xiWWlOMlNwcTdlbWV0ZWJ1TklZSkhBeWpvcHJSTDRwYU1Nbm5pNnd2VUwybTY4UHFZcmJNaF9OMUFRV3oxVzgyUW5leXF6LWtzcHQ4YVhUzJKLURuRURWNVpwSHNyRUZ0ZGpLQzMxT0laNVlGcm51ZVhwcFhxWll3Il0NCn0.G8yl1J1y5r8kE7d9dlnwnZ2Ug6yupIVqYl8J-XjAMBbi2c-rKGjx753-cxM1rLDS8KeQ0QqsGRwh09yU7kMlgAQuoR9gmTRPJuGDAk_dp2_JjV5C0QgIdGMZQvOyvCY9tjb1C6O4LlcxJR7G7GQ9hu2pOVlzYg8kkkgVLlN6bpVxenNfv1v8xh1Xyq_HBc8nloTRyDBXUbrVcLGl5H5pexHyHUQ7idCEoIIpycfMsqYuuJH_vVy3H_6ruYwcefrgzitzOtib6LaCHLkzxwVHd5t-IO6R6XUYs5dp5jqVrlxjCA_AncOIrO-ZDg7vL4IrVWSpR5qd0-NLk4IZ1nvtzA"
}

Appendix B. Glossary

Term Explanation
Access Token A unique value used to grant and request authorization to protected resources.
API Gateway A server that acts as a front-end receives API requests, enforces API usage policy, controls access, collects statistics, etc.
Claim A unique name/data pair describing information according to the RFC 7519 specification.
Client An application making protecting resource requests on behalf of the resource owner (RFC 6749).
DRS Data Repository Service. A system which provides data to consumers and conforms to the DRS specifications.
Embedded token

There are two types of embedded tokens: Embedded Access Tokens and Embedded Document Tokens.

Embedded Access Tokens are claims in a Broker’s token that can then be sent to OTHER brokers’ /userinfo endpoints for further user claims. In GA4GH Passports, embedded access tokens will usually carry full claims so as not to interrogate /userinfo each time.

Embedded Document Tokens cannot be revoked and no /userinfo endpoint is provided for them, however they still offer a signature that can be used to verify their provenance and always contain the necessary claims in them already.
FISMA Federal Information Security Management Act.
GA4GH Claim A JWT claim as defined by GA4GH documented technical standards.
ID Token A token containing claims about the identity of a person.
JWT According to RFC 7519, a JWT is a “JSON Web Token”, a compact means of representing claims.
OAuth An Authorization framework enabling third-party access on behalf of a resource owner to a protected resource (RFC 6749).
OIDC An acronym for OpenID Connect, a protocol which adds authentication and identity layer for OAuth 2.0.
Partner Organizations Partner Systems integrated with RAS.
Passport A GA4GH-compatible access token (“GA4GH Access Token”), as per the GA4GH AAI specification, along with the Passport Claim that is returned from Passport Broker service endpoints using such an access token.
Passport Claim A claim conforming to the GA4GH AAI specification.
Passport Visa According to the GA4GH Passport specification, a Visa is embedded in a Passport Claim and provides access information pertaining to authorization.
Refresh Token A token used to request a new Access Token.
Resource Owner A person or other entity capable of granting access to a protected resource (RFC 6749).
Resource Server The server hosting the protected resource (RFC 6749).

Appendix C. dbGaP Descriptions (Login Required)

Click here to find details on the different fields included in the RAS Database of Genotypes and Phenotypes (dbGaP).

Contact Us

For More Information: Please contact the NIH RAS Team.