eduKateSG · Why Science?
Let trusted research systems recognise a user across institutional boundaries—without confusing identity, credentials and permission
Choose the closest route, then return to the full index whenever you need the wider evidence chain.
Science learning becomes powerful when students can tell a measured pattern from a model, a statistical decision from a mechanism, and a useful lead from a finished conclusion. GA4GH Authorisation and Authentication Infrastructure (AAI) is a protocol framework for confirming a researcher’s digital identity and communicating permissions across compatible systems. GA4GH lists AAI as current and Support Ready, with v1.0 approved on 28 October 2019. It leverages OpenID Connect and uses access tokens to obtain GA4GH Passports containing Visa tokens; those portable assertions can be presented to data or analysis services that trust the relevant issuers. Authentication establishes who or what has authenticated, while authorisation applies local policy to a requested action. A valid token is not universal permission, scientific approval or evidence that every federation member trusts every issuer. This guide supports Primary Science, PSLE Science, Secondary Science, O-Level Science and STEM education as a longform evidence-reading route; it is not medical advice, a laboratory protocol, an admission promise or a career guarantee.
Related eduKate reading: GA4GH Passports, Visas and portable researcher access; GA4GH Data Repository Service and portable data access; Crypt4GH and encrypted genomic files; Science Learning Hub; Education Hub; STEM Education; Careers by Subject Capability.
Primary and official sources checked on 12 October 2026: Official GA4GH AAI product page, current v1.0; Official GA4GH AAI specification repository; Official OpenID Connect Core specification; 2026 Singapore–Cambridge O-Level Biology syllabus; MOE G2/G3 Lower Secondary Science teaching and learning syllabus; 2026 MOE G2 Computing syllabus. Standards, service interfaces and recommendations can change, so preserve the dated documentation and versions used.
A deeper reading route
AAI is an infrastructure pattern, not a single universal login screen. A researcher authenticates through an identity provider, a client obtains carefully scoped tokens, and a resource service decides whether the request is allowed. Federation becomes possible when organisations agree on protocols and trust relationships. Each participant still controls its accounts, keys, policies and protected resources.
OpenID Connect supplies a standard identity layer over OAuth 2.0. An identity token tells a client about an authenticated session, while an access token is presented to a protected resource. Treating the two as interchangeable is a classic implementation error. Token audience, issuer, scope and lifetime need validation before any claims are trusted.
GA4GH adds research-specific portability through Passports and Visas. An access token can be used to obtain a Passport containing signed Visa assertions, and compatible services can evaluate those assertions for later access requests. The receiving service checks its own trust framework and policy. Portability reduces repeated paperwork; it does not create a global administrator.
Federation changes the blast radius of mistakes. A weak issuer, stolen bearer token, overly broad audience or misconfigured redirect can affect more than one service. Good deployments use short lifetimes, narrow scopes, key rotation, secure transport, careful redirect registration and audit records that avoid copying reusable credentials into logs.
Availability and revocation are part of security. Identity providers, key endpoints and Passport brokers can fail or change. Systems need bounded cache rules and safe behaviour when freshness cannot be established. A cached key can support resilience, but indefinite trust can prolong a compromised or withdrawn identity.
For students, AAI resembles entering a science facility with a school identity card and a separate laboratory permission. The card helps establish identity; the permission applies to one activity; the laboratory still checks today’s safety and supervision rules. That friendly analogy preserves the serious distinction between who you are, what evidence you carry and what you may do now.
| Stage | Question | Evidence | Responsible output |
|---|---|---|---|
| Authenticate | Which user or client completed an identity flow? | Issuer, session and identity claims | An authenticated principal |
| Transport | Which bounded credentials reach the service? | Access token, Passport and signed Visas | Verifiable assertions |
| Authorise | May this principal perform this operation? | Audience, scope, issuer trust and local policy | A permit or deny decision |
| Audit | Can the decision be explained safely? | Event, policy, evidence references and time | A traceable security record |
Inside this guide
1–12 · Foundations and design
- 1. Start with the protected action
- 2. Understand the current specification
- 3. Separate authentication and authorisation
- 4. Use OpenID Connect deliberately
- 5. Identify the OpenID Provider
- 6. Identify the client
- 7. Identify the resource server
- 8. Distinguish ID and access tokens
- 9. Validate the issuer
- 10. Validate the audience
- 11. Validate time limits
- 12. Validate signatures and keys
13–24 · Models and estimation
- 13. Use scopes as request boundaries
- 14. Treat bearer tokens like credentials
- 15. Obtain the Passport through a defined flow
- 16. Read each Visa independently
- 17. Build a trust framework
- 18. Apply local policy at the service
- 19. Use least privilege
- 20. Plan revocation and withdrawal
- 21. Rotate keys safely
- 22. Handle provider outages
- 23. Protect redirect destinations
- 24. Minimise personal information
25–36 · Diagnostics and interpretation
- 25. Avoid account-linking mistakes
- 26. Connect access to data services
- 27. Connect encryption separately
- 28. Connect to Primary Science
- 29. Connect to Secondary Science
- 30. Connect to mathematics and logic
- 31. Connect to computing
- 32. Connect to pathways
- 33. Did you know?
- 34. Write a reader-ready access record
- 35. Build a validation ladder
- 36. Finish with a reproducible bundle
Section 1 of 36
1. Start with the protected action
Identity work should begin with a named resource and operation: discover metadata, retrieve an object or submit an analysis. Without that boundary, tokens tend to become broader than necessary.
Working checkpoint — AAI: Write the resource, operation and accountable policy owner first. Keep issuer, audience, scope, expiry, signature context, Passport evidence, policy and requested action together.
For a classroom model, use fictional badges and never real tokens or account data.
Section 2 of 36
2. Understand the current specification
GA4GH lists AAI as current and Support Ready and identifies v1.0, approved on 28 October 2019, as the last approved version.
Working checkpoint — OpenID Connect: Record the AAI profile, implementation and dated documentation. Read every valid token beside issuer authority, local trust, data-use conditions and the exact protected operation.
For future study, connect research identity to computing, cybersecurity and governance while checking official pathways separately.
Section 3 of 36
3. Separate authentication and authorisation
Authentication establishes an identity under an issuer’s process. Authorisation decides whether that identity and other evidence satisfy policy for a requested action.
Working checkpoint — authentication: Test the two decisions independently. Preserve denials and expiry failures without retaining secrets; successful access is not the complete security record.
For scientific writing, describe the trust path and decision without exposing credentials.
Section 4 of 36
4. Use OpenID Connect deliberately
GA4GH states that AAI leverages OpenID Connect to authenticate researchers and authorise access. Implementers still need the exact discovery, client and token rules in the profile.
Working checkpoint — authorisation: Validate against the documented profile rather than generic OAuth folklore. Separate authentication and token validity from authorisation, ethics approval and scientific suitability.
For students, ask who authenticated the user, what evidence travels and who decides the final permission.
Section 5 of 36
5. Identify the OpenID Provider
The provider issues identity information and tokens after an authentication flow. Its URL is a security identifier, not merely a convenient login address.
Working checkpoint — access token: Pin the expected issuer and retrieve its metadata securely. Treat issuer, audience, client, key and policy identifiers as security inputs: a silent mismatch can overgrant access.
For parents, ask whether the system shares only the identity details actually needed.
Section 6 of 36
6. Identify the client
The client initiates the flow and receives tokens for a registered purpose. Public, native and confidential clients have different abilities to protect secrets.
Working checkpoint — federated trust: Register redirect destinations and client type accurately. Keep issuer, audience, scope, expiry, signature context, Passport evidence, policy and requested action together.
For a classroom model, use fictional badges and never real tokens or account data.
Section 7 of 36
7. Identify the resource server
A data or analysis service receives an access token and enforces policy. It must not assume that successful token parsing equals authorisation.
Working checkpoint — AAI: Define the expected issuer, audience and operation at the resource. Read every valid token beside issuer authority, local trust, data-use conditions and the exact protected operation.
For future study, connect research identity to computing, cybersecurity and governance while checking official pathways separately.
Section 8 of 36
8. Distinguish ID and access tokens
An ID token is for the client’s authentication context; an access token is for a protected resource. Sending the wrong token to the wrong audience weakens boundaries.
Working checkpoint — OpenID Connect: Document which token each endpoint accepts. Preserve denials and expiry failures without retaining secrets; successful access is not the complete security record.
For scientific writing, describe the trust path and decision without exposing credentials.
Section 9 of 36
9. Validate the issuer
The issuer claim anchors the authority that created a token. Similar-looking domains or copied keys must not be accepted as substitutes.
Working checkpoint — authentication: Compare the exact issuer identifier with the configured trust record. Separate authentication and token validity from authorisation, ethics approval and scientific suitability.
For students, ask who authenticated the user, what evidence travels and who decides the final permission.
Section 10 of 36
10. Validate the audience
Audience limits which service or client a token is intended for. A valid signature with the wrong audience should still be rejected.
Working checkpoint — authorisation: Test cross-service replay as a negative fixture. Treat issuer, audience, client, key and policy identifiers as security inputs: a silent mismatch can overgrant access.
For parents, ask whether the system shares only the identity details actually needed.
Section 11 of 36
11. Validate time limits
Issued-at, expiry and related time claims bound the credential. Clock skew needs a small documented allowance, not unlimited acceptance.
Working checkpoint — access token: Synchronise clocks and log expiry failures without logging the token. Keep issuer, audience, scope, expiry, signature context, Passport evidence, policy and requested action together.
For a classroom model, use fictional badges and never real tokens or account data.
Section 12 of 36
12. Validate signatures and keys
A signature demonstrates integrity under a particular key. The service also needs a trusted path to current keys and a response to rotation or compromise.
Working checkpoint — federated trust: Cache keys with bounded freshness and handle unknown key IDs safely. Read every valid token beside issuer authority, local trust, data-use conditions and the exact protected operation.
For future study, connect research identity to computing, cybersecurity and governance while checking official pathways separately.
Section 13 of 36
13. Use scopes as request boundaries
Scopes communicate requested authority at a protocol layer. A scope is not a complete research policy and should not silently unlock unrelated operations.
Working checkpoint — AAI: Map every accepted scope to explicit endpoints and actions. Preserve denials and expiry failures without retaining secrets; successful access is not the complete security record.
For scientific writing, describe the trust path and decision without exposing credentials.
Section 14 of 36
14. Treat bearer tokens like credentials
Whoever possesses a bearer token may be able to present it. URLs, browser history, analytics and ordinary application logs are unsafe places for token material.
Working checkpoint — OpenID Connect: Use secure transport and redact credentials at every logging layer. Separate authentication and token validity from authorisation, ethics approval and scientific suitability.
For students, ask who authenticated the user, what evidence travels and who decides the final permission.
Section 15 of 36
15. Obtain the Passport through a defined flow
GA4GH describes access tokens being used to obtain Passports containing Visa tokens. The Passport endpoint and client need their own audience, scope and error handling.
Working checkpoint — authentication: Record the flow without preserving reusable token strings. Treat issuer, audience, client, key and policy identifiers as security inputs: a silent mismatch can overgrant access.
For parents, ask whether the system shares only the identity details actually needed.
Section 16 of 36
16. Read each Visa independently
A Passport can carry multiple signed assertions from different issuers and with different expiry times. One trusted Visa does not make every bundled claim trusted.
Working checkpoint — authorisation: Evaluate type, issuer, source and time for each Visa. Keep issuer, audience, scope, expiry, signature context, Passport evidence, policy and requested action together.
For a classroom model, use fictional badges and never real tokens or account data.
Section 17 of 36
17. Build a trust framework
Federation works when participants define which issuers may assert which facts for which resources. Trust should be scoped rather than inherited from technical compatibility.
Working checkpoint — access token: Create an issuer-by-claim authority matrix. Read every valid token beside issuer authority, local trust, data-use conditions and the exact protected operation.
For future study, connect research identity to computing, cybersecurity and governance while checking official pathways separately.
Section 18 of 36
18. Apply local policy at the service
The receiving service combines trusted assertions with its own rules, dataset conditions and requested operation. It remains accountable for the decision.
Working checkpoint — federated trust: Keep policy version and decision result together. Preserve denials and expiry failures without retaining secrets; successful access is not the complete security record.
For scientific writing, describe the trust path and decision without exposing credentials.
Section 19 of 36
19. Use least privilege
A researcher should receive only the scopes and assertions needed for the planned task, for no longer than necessary. Convenience is not a reason for universal tokens.
Working checkpoint — AAI: Reduce audience, scope and lifetime until each has a named need. Separate authentication and token validity from authorisation, ethics approval and scientific suitability.
For students, ask who authenticated the user, what evidence travels and who decides the final permission.
Section 20 of 36
20. Plan revocation and withdrawal
Expiry limits exposure, but urgent loss of affiliation or access may need revocation, deny lists or fresh policy checks. Federation partners need aligned response procedures.
Working checkpoint — OpenID Connect: Test a withdrawn credential before an incident. Treat issuer, audience, client, key and policy identifiers as security inputs: a silent mismatch can overgrant access.
For parents, ask whether the system shares only the identity details actually needed.
Section 21 of 36
21. Rotate keys safely
Key rotation should allow new signatures to validate without making old compromised material trustworthy forever. Caches and overlapping keys need explicit timing.
Working checkpoint — authentication: Exercise normal and emergency rotation in staging. Keep issuer, audience, scope, expiry, signature context, Passport evidence, policy and requested action together.
For a classroom model, use fictional badges and never real tokens or account data.
Section 22 of 36
22. Handle provider outages
An identity or Passport service can be unavailable while a resource remains online. Failing open may overgrant access; failing closed may interrupt research.
Working checkpoint — authorisation: Document bounded cache and fail-safe rules per operation. Read every valid token beside issuer authority, local trust, data-use conditions and the exact protected operation.
For future study, connect research identity to computing, cybersecurity and governance while checking official pathways separately.
Section 23 of 36
23. Protect redirect destinations
An attacker-controlled redirect can capture authorisation responses. Exact registration and secure application handling are core controls.
Working checkpoint — access token: Reject unregistered or ambiguous redirect URIs. Preserve denials and expiry failures without retaining secrets; successful access is not the complete security record.
For scientific writing, describe the trust path and decision without exposing credentials.
Section 24 of 36
24. Minimise personal information
Federated identity need not distribute a complete biography. Services should request only attributes required for the access decision.
Working checkpoint — federated trust: Review every claim for necessity and retention. Separate authentication and token validity from authorisation, ethics approval and scientific suitability.
For students, ask who authenticated the user, what evidence travels and who decides the final permission.
Section 25 of 36
25. Avoid account-linking mistakes
Two identifiers that look similar may represent different people, while one researcher can have several institutional identities. Automatic merging can misassign grants.
Working checkpoint — AAI: Require issuer-aware linking and a reviewable recovery path. Treat issuer, audience, client, key and policy identifiers as security inputs: a silent mismatch can overgrant access.
For parents, ask whether the system shares only the identity details actually needed.
Section 26 of 36
26. Connect access to data services
DRS or htsget can use AAI evidence to protect retrieval, but each API still defines its resource and response semantics. Credentials do not identify the correct dataset or reference.
Working checkpoint — OpenID Connect: Bind the decision to the exact service, object and operation. Keep issuer, audience, scope, expiry, signature context, Passport evidence, policy and requested action together.
For a classroom model, use fictional badges and never real tokens or account data.
Section 27 of 36
27. Connect encryption separately
Crypt4GH can protect genomic file contents while AAI governs who may receive access. Authentication does not replace encryption, and encryption does not decide policy.
Working checkpoint — authentication: Document identity, authorisation, key delivery and file protection as separate layers. Read every valid token beside issuer authority, local trust, data-use conditions and the exact protected operation.
For future study, connect research identity to computing, cybersecurity and governance while checking official pathways separately.
Section 28 of 36
28. Connect to Primary Science
A fictional laboratory badge can show identity, while a separate activity card shows today’s permission and safety conditions.
Working checkpoint — authorisation: Use made-up names and never real credentials. Preserve denials and expiry failures without retaining secrets; successful access is not the complete security record.
For scientific writing, describe the trust path and decision without exposing credentials.
Section 29 of 36
29. Connect to Secondary Science
Digital experiments rely on controlled access as well as sound method. A successful login says nothing about whether the analysis answers the scientific question.
Working checkpoint — access token: Add identity, permission and study-design gates to one workflow diagram. Separate authentication and token validity from authorisation, ethics approval and scientific suitability.
For students, ask who authenticated the user, what evidence travels and who decides the final permission.
Section 30 of 36
30. Connect to mathematics and logic
Set membership, Boolean policy, time intervals and graph trust relationships help explain why several individually valid claims may still fail one access rule.
Working checkpoint — federated trust: Build a truth table for issuer, scope, audience and expiry. Treat issuer, audience, client, key and policy identifiers as security inputs: a silent mismatch can overgrant access.
For parents, ask whether the system shares only the identity details actually needed.
Section 31 of 36
31. Connect to computing
Web redirects, JSON tokens, public-key signatures, discovery metadata and protected APIs make AAI a practical systems-security case study.
Working checkpoint — AAI: Test invalid issuer, wrong audience, expiry and key rotation. Keep issuer, audience, scope, expiry, signature context, Passport evidence, policy and requested action together.
For a classroom model, use fictional badges and never real tokens or account data.
Section 32 of 36
32. Connect to pathways
Federated research identity connects software engineering, cybersecurity, genomics operations, privacy and governance and can illuminate STEM pathways.
Working checkpoint — OpenID Connect: Check current official qualifications separately. Read every valid token beside issuer authority, local trust, data-use conditions and the exact protected operation.
For future study, connect research identity to computing, cybersecurity and governance while checking official pathways separately.
Section 33 of 36
33. Did you know?
GA4GH AAI uses an access token to obtain a Passport that can contain several Visa tokens. The layers let a service inspect research-specific assertions instead of treating login alone as permission.
Working checkpoint — authentication: Explain each layer before simplifying the diagram. Preserve denials and expiry failures without retaining secrets; successful access is not the complete security record.
For scientific writing, describe the trust path and decision without exposing credentials.
Section 34 of 36
34. Write a reader-ready access record
Name the issuer, client, service, requested action, accepted evidence types, policy version, decision time and outcome without exposing secrets.
Working checkpoint — authorisation: Reference tokens by safe identifiers or hashes only where approved. Separate authentication and token validity from authorisation, ethics approval and scientific suitability.
For students, ask who authenticated the user, what evidence travels and who decides the final permission.
Section 35 of 36
35. Build a validation ladder
Check discovery and TLS, validate issuer and audience, test times and signatures, evaluate Visas, apply policy, test withdrawal, then perform a minimal authorised action.
Working checkpoint — access token: Resolve the earliest failed layer before retrying. Treat issuer, audience, client, key and policy identifiers as security inputs: a silent mismatch can overgrant access.
For parents, ask whether the system shares only the identity details actually needed.
Section 36 of 36
36. Finish with a reproducible bundle
Deliver configuration versions, trust matrix, policy, test fixtures, rotation and outage results, redacted audit examples and service bindings.
Working checkpoint — federated trust: Make the decision explainable without retaining reusable credentials. Keep issuer, audience, scope, expiry, signature context, Passport evidence, policy and requested action together.
For a classroom model, use fictional badges and never real tokens or account data.
Contents · Previous section · Continue to the Science Learning Hub