तुमचे स्वतःचे API
ॲप तुमच्या API पैकी एकासाठी ॲक्सेस टोकन मागू शकते. त्याला सही केलेला JWT मिळतो ज्याचा ऑडियन्स ते API आहे आणि दुसरे काहीही नाही, आणि तुमचे API तो Usher ला कॉल न करता तुमच्या एन्व्हायर्नमेंटच्या प्रकाशित की ने तपासते. एका API साठीचे टोकन दुसऱ्या API वर काहीच कामाचे नसते.
API ला नाव द्या
Usher Console मध्ये, एन्व्हायर्नमेंट उघडा, मग ॲप्लिकेशन → तुमचे API → API जोडा. त्याला नाव आणि आयडेंटिफायर द्या: https:// पत्ता, जसे https://api.example.com, किंवा URN, जसे urn:example:api:notes. आयडेंटिफायर म्हणजे ॲप जे मागते आणि टोकनचा aud क्लेम जे सांगतो ते (RFC 8707).
मग ते API कॉल करणाऱ्या ॲप्सना द्या: प्रत्येक ॲप्लिकेशनवर API. ॲपने काहीही मागितले तरी, त्याला फक्त दिलेल्या API साठीच टोकन मिळतात. API काढून टाकले की ते आणखी टोकन देत नाही; आधीच दिलेले टोकन काही मिनिटांत संपतात.
ते मागा
ॲप त्याच्या ऑथरायझेशन विनंतीत आणि टोकन विनंत्यांत resource=<identifier> जोडते. मोबाइल SDK हे तुमच्यासाठी करतात:
let usher = UsherClient(configuration: .init(
issuer: URL(string: "https://login.example.com")!,
clientID: "…",
redirectURI: URL(string: "com.example.notes:/oauth/callback")!,
resources: ["urn:example:api:notes"]))
var request = URLRequest(url: URL(string: "https://api.example.com/notes")!)
try await usher.authorize(&request) // Authorization: Bearer <a JWT for the Notes API>val usher = Usher.client(context, UsherConfiguration(
issuer = "https://login.example.com",
clientId = "…",
redirectUri = "com.example.notes:/oauth/callback",
resources = listOf("urn:example:api:notes")))तुमचे दोन API कॉल करणारे ॲप दोन्ही एकाच वेळी मागू शकते; मग टोकनच्या ऑडियन्समध्ये दोन्ही असतात.
ते तुमच्या API मध्ये तपासा
टोकनमधील कशावरही विश्वास ठेवण्यापूर्वी प्रत्येक विनंतीचे टोकन तपासा:
- सही, तुमच्या एन्व्हायर्नमेंटच्या डिस्कव्हरी दस्तऐवजातील
jwks_uriवरील की विरुद्ध. अल्गोरिदम की मधून घ्या, टोकनच्या हेडरमधून कधीही नाही. issहा अगदी तुमच्या एन्व्हायर्नमेंटचा इश्युअर आहे. तो तुमच्या कॉन्फिगरेशनमध्ये निश्चित करा; टोकनमधून कधीही वाचू नका.audमध्ये तुमच्या API चा आयडेंटिफायर आहे. (openidस्कोपसह त्यात तुमच्या एन्व्हायर्नमेंटचा userinfo पत्ताही असतो.)- हेडरमधील
typहाat+jwtआहे, म्हणजे ID टोकन ॲक्सेस टोकन म्हणून खपवता येत नाही. expउलटलेला नाही. ॲक्सेस टोकन 10 मिनिटे टिकतात; SDK ते तुमच्यासाठी रिफ्रेश करतात.
Node.js मध्ये, @usher/node हे सर्व करते:
import { createVerifier } from '@usher/node'
const usher = await createVerifier({
issuer: 'https://login.example.com',
audience: 'urn:example:api:notes',
})
const claims = await usher.accessToken(bearerToken) // throws if any check failsASP.NET Core मध्ये:
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(o =>
{
o.Authority = "https://login.example.com"; // discovery and keys come from here
o.MapInboundClaims = false;
o.TokenValidationParameters = new()
{
ValidIssuer = "https://login.example.com",
ValidAudience = "urn:example:api:notes",
ValidTypes = ["at+jwt"],
};
});टोकन काय सांगते
| क्लेम | |
|---|---|
sub | व्यक्ती. iss सोबत, तिला ओळखून ठेवण्याची की. |
client_id, azp | विचारणारे ॲप. |
scope | ॲप काय करू शकते याला व्यक्तीने दिलेली संमती. |
email, email_verified | email स्कोपसह: व्यक्तीचा पत्ता, आणि तो तिचाच असल्याचे Usher ने सिद्ध केले आहे की नाही. |
sid | त्यांचे साइन-इन सेशन. |
org | organization स्कोपसह: त्यांची सक्रिय संस्था आणि भूमिका. |
तुम्ही आधीच ओळखत असलेले लोक
तुमच्या API मध्ये आधीपासूनची खाती असल्यास, व्यक्ती पहिल्यांदा Usher टोकनसह आल्यावर तुम्ही तिचे खाते शोधू शकता: email ने शोधा, फक्त email_verified हे true असेल तेव्हाच, आणि तेव्हापासून iss आणि sub तिच्या खात्यावर ठेवा. त्यानंतर, तिला iss आणि sub ने शोधा, ईमेलने कधीही नाही: पत्ता दुसऱ्याच्या हातात जाऊ शकतो, सबजेक्ट कधीच जात नाही.