ನಿಮ್ಮದೇ API ಗಳು

ಒಂದು ಆ್ಯಪ್ ನಿಮ್ಮ API ಗಳಲ್ಲಿ ಒಂದಕ್ಕಾಗಿ ಆ್ಯಕ್ಸೆಸ್ ಟೋಕನ್ ಕೇಳಬಹುದು. ಅದಕ್ಕೆ ಸಿಗುವುದು ಸಹಿ ಮಾಡಿದ ಒಂದು JWT, ಅದರ audience ಆ API ಮಾತ್ರ, ಬೇರೇನೂ ಅಲ್ಲ; ಮತ್ತು ನಿಮ್ಮ API ಅದನ್ನು Usher ಅನ್ನು ಕರೆಯದೆಯೇ ನಿಮ್ಮ ಎನ್ವಿರಾನ್‌ಮೆಂಟ್‌ನ ಪ್ರಕಟಿತ ಕೀಗಳಿಂದ ಪರಿಶೀಲಿಸುತ್ತದೆ. ಒಂದು API ಗಾಗಿರುವ ಟೋಕನ್ ಇನ್ನೊಂದರಲ್ಲಿ ಉಪಯೋಗವಿಲ್ಲ.

API ಗೆ ಹೆಸರಿಡಿ

Usher Console ನಲ್ಲಿ ಎನ್ವಿರಾನ್‌ಮೆಂಟ್ ತೆರೆಯಿರಿ, ನಂತರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು → ನಿಮ್ಮ API ಗಳು → API ಸೇರಿಸಿ. ಅದಕ್ಕೆ ಒಂದು ಹೆಸರು ಮತ್ತು ಒಂದು ಗುರುತಿಸುವಿಕೆ (identifier) ನೀಡಿ: https://api.example.com ನಂತಹ https:// ವಿಳಾಸ, ಅಥವಾ urn:example:api:notes ನಂತಹ URN. ಆ್ಯಪ್ ಕೇಳುವುದು ಮತ್ತು ಟೋಕನ್‌ನ aud ಕ್ಲೇಮ್ ಹೇಳುವುದು ಈ ಗುರುತಿಸುವಿಕೆಯನ್ನೇ (RFC 8707).

ನಂತರ ಆ API ಅನ್ನು ಅದನ್ನು ಕರೆಯುವ ಆ್ಯಪ್‌ಗಳಿಗೆ ನೀಡಿ: ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ API ಗಳು. ಆ್ಯಪ್ ಏನನ್ನು ಕೇಳಿದರೂ, ಅದಕ್ಕೆ ನೀಡಲಾದ API ಗಳಿಗಾಗಿ ಮಾತ್ರ ಟೋಕನ್‌ಗಳು ಸಿಗುತ್ತವೆ. API ಅನ್ನು ತೆಗೆದುಹಾಕಿದರೆ ಅದಕ್ಕೆ ಇನ್ನು ಟೋಕನ್‌ಗಳು ಸಿಗುವುದಿಲ್ಲ; ಈಗಾಗಲೇ ನೀಡಿರುವವು ಕೆಲವೇ ನಿಮಿಷಗಳಲ್ಲಿ ಅವಧಿ ಮುಗಿಯುತ್ತವೆ.

ಅದನ್ನು ಕೇಳಿ

ಆ್ಯಪ್ ತನ್ನ authorization ವಿನಂತಿಗೆ ಮತ್ತು ಟೋಕನ್ ವಿನಂತಿಗಳಿಗೆ 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 ಗಳನ್ನು ಕರೆಯುವ ಆ್ಯಪ್ ಎರಡನ್ನೂ ಒಮ್ಮೆಗೇ ಕೇಳಬಹುದು; ಆಗ ಟೋಕನ್‌ನ audience ಎರಡನ್ನೂ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ.

ನಿಮ್ಮ 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 fails

ASP.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"],
        };
    });

ಟೋಕನ್ ಏನು ಹೇಳುತ್ತದೆ

ನಿಮಗೆ ಈಗಾಗಲೇ ಪರಿಚಯವಿರುವ ಜನರು

ನಿಮ್ಮ API ನಲ್ಲಿ ಹಿಂದಿನಿಂದಲೇ ಖಾತೆಗಳಿದ್ದರೆ, ಒಬ್ಬ ವ್ಯಕ್ತಿ Usher ಟೋಕನ್‌ನೊಂದಿಗೆ ಮೊದಲ ಬಾರಿ ಬಂದಾಗ ಅವರ ಖಾತೆಯನ್ನು ಹುಡುಕಬಹುದು: ಅವರನ್ನು email ಮೂಲಕ ಹುಡುಕಿ, email_verified ಎಂಬುದು true ಆಗಿದ್ದಾಗ ಮಾತ್ರ, ಮತ್ತು ಅಂದಿನಿಂದ ಅವರ ಖಾತೆಯಲ್ಲಿ iss ಮತ್ತು sub ಇಟ್ಟುಕೊಳ್ಳಿ. ಅದರ ನಂತರ, ಅವರನ್ನು iss ಮತ್ತು sub ಮೂಲಕ ಹುಡುಕಿ, ಇಮೇಲ್ ಮೂಲಕ ಎಂದಿಗೂ ಅಲ್ಲ: ಒಂದು ವಿಳಾಸ ಬೇರೊಬ್ಬರ ಕೈಗೆ ಹೋಗಬಹುದು, ಆದರೆ subject ಎಂದಿಗೂ ಹೋಗುವುದಿಲ್ಲ.