├── .github ├── PULL_REQUEST_TEMPLATE.md └── workflows │ ├── deploy.yml │ └── main.yml ├── .gitignore ├── LICENSE ├── README.md ├── astro.config.mjs ├── package.json ├── pnpm-lock.yaml ├── public ├── 47b9e55389f64921b44796a80c2538b4.txt ├── apple-touch-icon.png ├── favicon-160x160.png ├── favicon-16x16.png ├── favicon-32x32.png ├── logo-dark.svg ├── logo-light.svg └── logo.svg ├── renovate.json ├── src ├── assets │ ├── banner.svg │ └── cover.png ├── components │ ├── BackgroundBanner.astro │ ├── BackgroundCells.astro │ ├── ByLogto.astro │ ├── Card.astro │ ├── FancyHr.astro │ ├── Footer.astro │ ├── LanguageSelector.astro │ ├── Logo.astro │ ├── Share.astro │ ├── ShareButton.astro │ ├── Tags.astro │ └── Topbar.astro ├── content │ ├── config.ts │ └── terms │ │ ├── ar │ │ ├── abac.mdx │ │ ├── access-control.mdx │ │ ├── access-token.mdx │ │ ├── api-key.mdx │ │ ├── audience.mdx │ │ ├── auth.mdx │ │ ├── authentication-request.mdx │ │ ├── authentication.mdx │ │ ├── authorization-code-flow.mdx │ │ ├── authorization-request.mdx │ │ ├── authorization-server-metadata.mdx │ │ ├── authorization-server.mdx │ │ ├── authorization.mdx │ │ ├── backup code.mdx │ │ ├── claim.mdx │ │ ├── client-credentials-flow.mdx │ │ ├── client.mdx │ │ ├── csprng.mdx │ │ ├── csrf.mdx │ │ ├── device-flow.mdx │ │ ├── enterprise-sso.mdx │ │ ├── hybrid-flow.mdx │ │ ├── iam.mdx │ │ ├── id-token.mdx │ │ ├── identity-provider.mdx │ │ ├── implicit-flow.mdx │ │ ├── jit-provisioning.mdx │ │ ├── jwe.mdx │ │ ├── jwk.mdx │ │ ├── jws.mdx │ │ ├── jwt.mdx │ │ ├── machine-to-machine.mdx │ │ ├── magic-link.mdx │ │ ├── management-api.mdx │ │ ├── mfa.mdx │ │ ├── multi-tenancy.mdx │ │ ├── oauth-2.0-grant.mdx │ │ ├── oauth-2.0.mdx │ │ ├── oauth-2.1.mdx │ │ ├── offline-access.mdx │ │ ├── opaque-token.mdx │ │ ├── openid-connect-discovery.mdx │ │ ├── openid-connect.mdx │ │ ├── otp.mdx │ │ ├── passkey.mdx │ │ ├── passwordless.mdx │ │ ├── pkce.mdx │ │ ├── protected-resource-metadata.mdx │ │ ├── rbac.mdx │ │ ├── redirect-uri.mdx │ │ ├── refresh-token.mdx │ │ ├── resource-indicator.mdx │ │ ├── resource-owner.mdx │ │ ├── resource-server.mdx │ │ ├── role.mdx │ │ ├── saml.mdx │ │ ├── scope.mdx │ │ ├── service-provider.mdx │ │ ├── signing-key.mdx │ │ ├── single-sign-on.mdx │ │ ├── token-introspection.mdx │ │ ├── token-request.mdx │ │ ├── totp.mdx │ │ ├── userinfo-endpoint.mdx │ │ ├── webauthn.mdx │ │ ├── webhook.mdx │ │ └── xacml.mdx │ │ ├── de │ │ ├── abac.mdx │ │ ├── access-control.mdx │ │ ├── access-token.mdx │ │ ├── api-key.mdx │ │ ├── audience.mdx │ │ ├── auth.mdx │ │ ├── authentication-request.mdx │ │ ├── authentication.mdx │ │ ├── authorization-code-flow.mdx │ │ ├── authorization-request.mdx │ │ ├── authorization-server-metadata.mdx │ │ ├── authorization-server.mdx │ │ ├── authorization.mdx │ │ ├── backup code.mdx │ │ ├── claim.mdx │ │ ├── client-credentials-flow.mdx │ │ ├── client.mdx │ │ ├── csprng.mdx │ │ ├── csrf.mdx │ │ ├── device-flow.mdx │ │ ├── enterprise-sso.mdx │ │ ├── hybrid-flow.mdx │ │ ├── iam.mdx │ │ ├── id-token.mdx │ │ ├── identity-provider.mdx │ │ ├── implicit-flow.mdx │ │ ├── jit-provisioning.mdx │ │ ├── jwe.mdx │ │ ├── jwk.mdx │ │ ├── jws.mdx │ │ ├── jwt.mdx │ │ ├── machine-to-machine.mdx │ │ ├── magic-link.mdx │ │ ├── management-api.mdx │ │ ├── mfa.mdx │ │ ├── multi-tenancy.mdx │ │ ├── oauth-2.0-grant.mdx │ │ ├── oauth-2.0.mdx │ │ ├── oauth-2.1.mdx │ │ ├── offline-access.mdx │ │ ├── opaque-token.mdx │ │ ├── openid-connect-discovery.mdx │ │ ├── openid-connect.mdx │ │ ├── otp.mdx │ │ ├── passkey.mdx │ │ ├── passwordless.mdx │ │ ├── pkce.mdx │ │ ├── protected-resource-metadata.mdx │ │ ├── rbac.mdx │ │ ├── redirect-uri.mdx │ │ ├── refresh-token.mdx │ │ ├── resource-indicator.mdx │ │ ├── resource-owner.mdx │ │ ├── resource-server.mdx │ │ ├── role.mdx │ │ ├── saml.mdx │ │ ├── scope.mdx │ │ ├── service-provider.mdx │ │ ├── signing-key.mdx │ │ ├── single-sign-on.mdx │ │ ├── token-introspection.mdx │ │ ├── token-request.mdx │ │ ├── totp.mdx │ │ ├── userinfo-endpoint.mdx │ │ ├── webauthn.mdx │ │ ├── webhook.mdx │ │ └── xacml.mdx │ │ ├── en │ │ ├── abac.mdx │ │ ├── access-control.mdx │ │ ├── access-token.mdx │ │ ├── api-key.mdx │ │ ├── audience.mdx │ │ ├── auth.mdx │ │ ├── authentication-request.mdx │ │ ├── authentication.mdx │ │ ├── authorization-code-flow.mdx │ │ ├── authorization-request.mdx │ │ ├── authorization-server-metadata.mdx │ │ ├── authorization-server.mdx │ │ ├── authorization.mdx │ │ ├── backup code.mdx │ │ ├── claim.mdx │ │ ├── client-credentials-flow.mdx │ │ ├── client.mdx │ │ ├── csprng.mdx │ │ ├── csrf.mdx │ │ ├── device-flow.mdx │ │ ├── enterprise-sso.mdx │ │ ├── hybrid-flow.mdx │ │ ├── iam.mdx │ │ ├── id-token.mdx │ │ ├── identity-provider.mdx │ │ ├── implicit-flow.mdx │ │ ├── jit-provisioning.mdx │ │ ├── jwe.mdx │ │ ├── jwk.mdx │ │ ├── jws.mdx │ │ ├── jwt.mdx │ │ ├── machine-to-machine.mdx │ │ ├── magic-link.mdx │ │ ├── management-api.mdx │ │ ├── mfa.mdx │ │ ├── multi-tenancy.mdx │ │ ├── oauth-2.0-grant.mdx │ │ ├── oauth-2.0.mdx │ │ ├── oauth-2.1.mdx │ │ ├── offline-access.mdx │ │ ├── opaque-token.mdx │ │ ├── openid-connect-discovery.mdx │ │ ├── openid-connect.mdx │ │ ├── otp.mdx │ │ ├── passkey.mdx │ │ ├── passwordless.mdx │ │ ├── pkce.mdx │ │ ├── protected-resource-metadata.mdx │ │ ├── rbac.mdx │ │ ├── redirect-uri.mdx │ │ ├── refresh-token.mdx │ │ ├── resource-indicator.mdx │ │ ├── resource-owner.mdx │ │ ├── resource-server.mdx │ │ ├── role.mdx │ │ ├── saml.mdx │ │ ├── scope.mdx │ │ ├── service-provider.mdx │ │ ├── signing-key.mdx │ │ ├── single-sign-on.mdx │ │ ├── token-introspection.mdx │ │ ├── token-request.mdx │ │ ├── totp.mdx │ │ ├── userinfo-endpoint.mdx │ │ ├── webauthn.mdx │ │ ├── webhook.mdx │ │ └── xacml.mdx │ │ ├── es │ │ ├── abac.mdx │ │ ├── access-control.mdx │ │ ├── access-token.mdx │ │ ├── api-key.mdx │ │ ├── audience.mdx │ │ ├── auth.mdx │ │ ├── authentication-request.mdx │ │ ├── authentication.mdx │ │ ├── authorization-code-flow.mdx │ │ ├── authorization-request.mdx │ │ ├── authorization-server-metadata.mdx │ │ ├── authorization-server.mdx │ │ ├── authorization.mdx │ │ ├── backup code.mdx │ │ ├── claim.mdx │ │ ├── client-credentials-flow.mdx │ │ ├── client.mdx │ │ ├── csprng.mdx │ │ ├── csrf.mdx │ │ ├── device-flow.mdx │ │ ├── enterprise-sso.mdx │ │ ├── hybrid-flow.mdx │ │ ├── iam.mdx │ │ ├── id-token.mdx │ │ ├── identity-provider.mdx │ │ ├── implicit-flow.mdx │ │ ├── jit-provisioning.mdx │ │ ├── jwe.mdx │ │ ├── jwk.mdx │ │ ├── jws.mdx │ │ ├── jwt.mdx │ │ ├── machine-to-machine.mdx │ │ ├── magic-link.mdx │ │ ├── management-api.mdx │ │ ├── mfa.mdx │ │ ├── multi-tenancy.mdx │ │ ├── oauth-2.0-grant.mdx │ │ ├── oauth-2.0.mdx │ │ ├── oauth-2.1.mdx │ │ ├── offline-access.mdx │ │ ├── opaque-token.mdx │ │ ├── openid-connect-discovery.mdx │ │ ├── openid-connect.mdx │ │ ├── otp.mdx │ │ ├── passkey.mdx │ │ ├── passwordless.mdx │ │ ├── pkce.mdx │ │ ├── protected-resource-metadata.mdx │ │ ├── rbac.mdx │ │ ├── redirect-uri.mdx │ │ ├── refresh-token.mdx │ │ ├── resource-indicator.mdx │ │ ├── resource-owner.mdx │ │ ├── resource-server.mdx │ │ ├── role.mdx │ │ ├── saml.mdx │ │ ├── scope.mdx │ │ ├── service-provider.mdx │ │ ├── signing-key.mdx │ │ ├── single-sign-on.mdx │ │ ├── token-introspection.mdx │ │ ├── token-request.mdx │ │ ├── totp.mdx │ │ ├── userinfo-endpoint.mdx │ │ ├── webauthn.mdx │ │ ├── webhook.mdx │ │ └── xacml.mdx │ │ ├── fr │ │ ├── abac.mdx │ │ ├── access-control.mdx │ │ ├── access-token.mdx │ │ ├── api-key.mdx │ │ ├── audience.mdx │ │ ├── auth.mdx │ │ ├── authentication-request.mdx │ │ ├── authentication.mdx │ │ ├── authorization-code-flow.mdx │ │ ├── authorization-request.mdx │ │ ├── authorization-server-metadata.mdx │ │ ├── authorization-server.mdx │ │ ├── authorization.mdx │ │ ├── backup code.mdx │ │ ├── claim.mdx │ │ ├── client-credentials-flow.mdx │ │ ├── client.mdx │ │ ├── csprng.mdx │ │ ├── csrf.mdx │ │ ├── device-flow.mdx │ │ ├── enterprise-sso.mdx │ │ ├── hybrid-flow.mdx │ │ ├── iam.mdx │ │ ├── id-token.mdx │ │ ├── identity-provider.mdx │ │ ├── implicit-flow.mdx │ │ ├── jit-provisioning.mdx │ │ ├── jwe.mdx │ │ ├── jwk.mdx │ │ ├── jws.mdx │ │ ├── jwt.mdx │ │ ├── machine-to-machine.mdx │ │ ├── magic-link.mdx │ │ ├── management-api.mdx │ │ ├── mfa.mdx │ │ ├── multi-tenancy.mdx │ │ ├── oauth-2.0-grant.mdx │ │ ├── oauth-2.0.mdx │ │ ├── oauth-2.1.mdx │ │ ├── offline-access.mdx │ │ ├── opaque-token.mdx │ │ ├── openid-connect-discovery.mdx │ │ ├── openid-connect.mdx │ │ ├── otp.mdx │ │ ├── passkey.mdx │ │ ├── passwordless.mdx │ │ ├── pkce.mdx │ │ ├── protected-resource-metadata.mdx │ │ ├── rbac.mdx │ │ ├── redirect-uri.mdx │ │ ├── refresh-token.mdx │ │ ├── resource-indicator.mdx │ │ ├── resource-owner.mdx │ │ ├── resource-server.mdx │ │ ├── role.mdx │ │ ├── saml.mdx │ │ ├── scope.mdx │ │ ├── service-provider.mdx │ │ ├── signing-key.mdx │ │ ├── single-sign-on.mdx │ │ ├── token-introspection.mdx │ │ ├── token-request.mdx │ │ ├── totp.mdx │ │ ├── userinfo-endpoint.mdx │ │ ├── webauthn.mdx │ │ ├── webhook.mdx │ │ └── xacml.mdx │ │ ├── it │ │ ├── abac.mdx │ │ ├── access-control.mdx │ │ ├── access-token.mdx │ │ ├── api-key.mdx │ │ ├── audience.mdx │ │ ├── auth.mdx │ │ ├── authentication-request.mdx │ │ ├── authentication.mdx │ │ ├── authorization-code-flow.mdx │ │ ├── authorization-request.mdx │ │ ├── authorization-server-metadata.mdx │ │ ├── authorization-server.mdx │ │ ├── authorization.mdx │ │ ├── backup code.mdx │ │ ├── claim.mdx │ │ ├── client-credentials-flow.mdx │ │ ├── client.mdx │ │ ├── csprng.mdx │ │ ├── csrf.mdx │ │ ├── device-flow.mdx │ │ ├── enterprise-sso.mdx │ │ ├── hybrid-flow.mdx │ │ ├── iam.mdx │ │ ├── id-token.mdx │ │ ├── identity-provider.mdx │ │ ├── implicit-flow.mdx │ │ ├── jit-provisioning.mdx │ │ ├── jwe.mdx │ │ ├── jwk.mdx │ │ ├── jws.mdx │ │ ├── jwt.mdx │ │ ├── machine-to-machine.mdx │ │ ├── magic-link.mdx │ │ ├── management-api.mdx │ │ ├── mfa.mdx │ │ ├── multi-tenancy.mdx │ │ ├── oauth-2.0-grant.mdx │ │ ├── oauth-2.0.mdx │ │ ├── oauth-2.1.mdx │ │ ├── offline-access.mdx │ │ ├── opaque-token.mdx │ │ ├── openid-connect-discovery.mdx │ │ ├── openid-connect.mdx │ │ ├── otp.mdx │ │ ├── passkey.mdx │ │ ├── passwordless.mdx │ │ ├── pkce.mdx │ │ ├── protected-resource-metadata.mdx │ │ ├── rbac.mdx │ │ ├── redirect-uri.mdx │ │ ├── refresh-token.mdx │ │ ├── resource-indicator.mdx │ │ ├── resource-owner.mdx │ │ ├── resource-server.mdx │ │ ├── role.mdx │ │ ├── saml.mdx │ │ ├── scope.mdx │ │ ├── service-provider.mdx │ │ ├── signing-key.mdx │ │ ├── single-sign-on.mdx │ │ ├── token-introspection.mdx │ │ ├── token-request.mdx │ │ ├── totp.mdx │ │ ├── userinfo-endpoint.mdx │ │ ├── webauthn.mdx │ │ ├── webhook.mdx │ │ └── xacml.mdx │ │ ├── ja │ │ ├── abac.mdx │ │ ├── access-control.mdx │ │ ├── access-token.mdx │ │ ├── api-key.mdx │ │ ├── audience.mdx │ │ ├── auth.mdx │ │ ├── authentication-request.mdx │ │ ├── authentication.mdx │ │ ├── authorization-code-flow.mdx │ │ ├── authorization-request.mdx │ │ ├── authorization-server-metadata.mdx │ │ ├── authorization-server.mdx │ │ ├── authorization.mdx │ │ ├── backup code.mdx │ │ ├── claim.mdx │ │ ├── client-credentials-flow.mdx │ │ ├── client.mdx │ │ ├── csprng.mdx │ │ ├── csrf.mdx │ │ ├── device-flow.mdx │ │ ├── enterprise-sso.mdx │ │ ├── hybrid-flow.mdx │ │ ├── iam.mdx │ │ ├── id-token.mdx │ │ ├── identity-provider.mdx │ │ ├── implicit-flow.mdx │ │ ├── jit-provisioning.mdx │ │ ├── jwe.mdx │ │ ├── jwk.mdx │ │ ├── jws.mdx │ │ ├── jwt.mdx │ │ ├── machine-to-machine.mdx │ │ ├── magic-link.mdx │ │ ├── management-api.mdx │ │ ├── mfa.mdx │ │ ├── multi-tenancy.mdx │ │ ├── oauth-2.0-grant.mdx │ │ ├── oauth-2.0.mdx │ │ ├── oauth-2.1.mdx │ │ ├── offline-access.mdx │ │ ├── opaque-token.mdx │ │ ├── openid-connect-discovery.mdx │ │ ├── openid-connect.mdx │ │ ├── otp.mdx │ │ ├── passkey.mdx │ │ ├── passwordless.mdx │ │ ├── pkce.mdx │ │ ├── protected-resource-metadata.mdx │ │ ├── rbac.mdx │ │ ├── redirect-uri.mdx │ │ ├── refresh-token.mdx │ │ ├── resource-indicator.mdx │ │ ├── resource-owner.mdx │ │ ├── resource-server.mdx │ │ ├── role.mdx │ │ ├── saml.mdx │ │ ├── scope.mdx │ │ ├── service-provider.mdx │ │ ├── signing-key.mdx │ │ ├── single-sign-on.mdx │ │ ├── token-introspection.mdx │ │ ├── token-request.mdx │ │ ├── totp.mdx │ │ ├── userinfo-endpoint.mdx │ │ ├── webauthn.mdx │ │ ├── webhook.mdx │ │ └── xacml.mdx │ │ ├── ko │ │ ├── abac.mdx │ │ ├── access-control.mdx │ │ ├── access-token.mdx │ │ ├── api-key.mdx │ │ ├── audience.mdx │ │ ├── auth.mdx │ │ ├── authentication-request.mdx │ │ ├── authentication.mdx │ │ ├── authorization-code-flow.mdx │ │ ├── authorization-request.mdx │ │ ├── authorization-server-metadata.mdx │ │ ├── authorization-server.mdx │ │ ├── authorization.mdx │ │ ├── backup code.mdx │ │ ├── claim.mdx │ │ ├── client-credentials-flow.mdx │ │ ├── client.mdx │ │ ├── csprng.mdx │ │ ├── csrf.mdx │ │ ├── device-flow.mdx │ │ ├── enterprise-sso.mdx │ │ ├── hybrid-flow.mdx │ │ ├── iam.mdx │ │ ├── id-token.mdx │ │ ├── identity-provider.mdx │ │ ├── implicit-flow.mdx │ │ ├── jit-provisioning.mdx │ │ ├── jwe.mdx │ │ ├── jwk.mdx │ │ ├── jws.mdx │ │ ├── jwt.mdx │ │ ├── machine-to-machine.mdx │ │ ├── magic-link.mdx │ │ ├── management-api.mdx │ │ ├── mfa.mdx │ │ ├── multi-tenancy.mdx │ │ ├── oauth-2.0-grant.mdx │ │ ├── oauth-2.0.mdx │ │ ├── oauth-2.1.mdx │ │ ├── offline-access.mdx │ │ ├── opaque-token.mdx │ │ ├── openid-connect-discovery.mdx │ │ ├── openid-connect.mdx │ │ ├── otp.mdx │ │ ├── passkey.mdx │ │ ├── passwordless.mdx │ │ ├── pkce.mdx │ │ ├── protected-resource-metadata.mdx │ │ ├── rbac.mdx │ │ ├── redirect-uri.mdx │ │ ├── refresh-token.mdx │ │ ├── resource-indicator.mdx │ │ ├── resource-owner.mdx │ │ ├── resource-server.mdx │ │ ├── role.mdx │ │ ├── saml.mdx │ │ ├── scope.mdx │ │ ├── service-provider.mdx │ │ ├── signing-key.mdx │ │ ├── single-sign-on.mdx │ │ ├── token-introspection.mdx │ │ ├── token-request.mdx │ │ ├── totp.mdx │ │ ├── userinfo-endpoint.mdx │ │ ├── webauthn.mdx │ │ ├── webhook.mdx │ │ └── xacml.mdx │ │ ├── nl │ │ ├── abac.mdx │ │ ├── access-control.mdx │ │ ├── access-token.mdx │ │ ├── api-key.mdx │ │ ├── audience.mdx │ │ ├── auth.mdx │ │ ├── authentication-request.mdx │ │ ├── authentication.mdx │ │ ├── authorization-code-flow.mdx │ │ ├── authorization-request.mdx │ │ ├── authorization-server-metadata.mdx │ │ ├── authorization-server.mdx │ │ ├── authorization.mdx │ │ ├── backup code.mdx │ │ ├── claim.mdx │ │ ├── client-credentials-flow.mdx │ │ ├── client.mdx │ │ ├── csprng.mdx │ │ ├── csrf.mdx │ │ ├── device-flow.mdx │ │ ├── enterprise-sso.mdx │ │ ├── hybrid-flow.mdx │ │ ├── iam.mdx │ │ ├── id-token.mdx │ │ ├── identity-provider.mdx │ │ ├── implicit-flow.mdx │ │ ├── jit-provisioning.mdx │ │ ├── jwe.mdx │ │ ├── jwk.mdx │ │ ├── jws.mdx │ │ ├── jwt.mdx │ │ ├── machine-to-machine.mdx │ │ ├── magic-link.mdx │ │ ├── management-api.mdx │ │ ├── mfa.mdx │ │ ├── multi-tenancy.mdx │ │ ├── oauth-2.0-grant.mdx │ │ ├── oauth-2.0.mdx │ │ ├── oauth-2.1.mdx │ │ ├── offline-access.mdx │ │ ├── opaque-token.mdx │ │ ├── openid-connect-discovery.mdx │ │ ├── openid-connect.mdx │ │ ├── otp.mdx │ │ ├── passkey.mdx │ │ ├── passwordless.mdx │ │ ├── pkce.mdx │ │ ├── protected-resource-metadata.mdx │ │ ├── rbac.mdx │ │ ├── redirect-uri.mdx │ │ ├── refresh-token.mdx │ │ ├── resource-indicator.mdx │ │ ├── resource-owner.mdx │ │ ├── resource-server.mdx │ │ ├── role.mdx │ │ ├── saml.mdx │ │ ├── scope.mdx │ │ ├── service-provider.mdx │ │ ├── signing-key.mdx │ │ ├── single-sign-on.mdx │ │ ├── token-introspection.mdx │ │ ├── token-request.mdx │ │ ├── totp.mdx │ │ ├── userinfo-endpoint.mdx │ │ ├── webauthn.mdx │ │ ├── webhook.mdx │ │ └── xacml.mdx │ │ ├── pt-br │ │ ├── abac.mdx │ │ ├── access-control.mdx │ │ ├── access-token.mdx │ │ ├── api-key.mdx │ │ ├── audience.mdx │ │ ├── auth.mdx │ │ ├── authentication-request.mdx │ │ ├── authentication.mdx │ │ ├── authorization-code-flow.mdx │ │ ├── authorization-request.mdx │ │ ├── authorization-server-metadata.mdx │ │ ├── authorization-server.mdx │ │ ├── authorization.mdx │ │ ├── backup code.mdx │ │ ├── claim.mdx │ │ ├── client-credentials-flow.mdx │ │ ├── client.mdx │ │ ├── csprng.mdx │ │ ├── csrf.mdx │ │ ├── device-flow.mdx │ │ ├── enterprise-sso.mdx │ │ ├── hybrid-flow.mdx │ │ ├── iam.mdx │ │ ├── id-token.mdx │ │ ├── identity-provider.mdx │ │ ├── implicit-flow.mdx │ │ ├── jit-provisioning.mdx │ │ ├── jwe.mdx │ │ ├── jwk.mdx │ │ ├── jws.mdx │ │ ├── jwt.mdx │ │ ├── machine-to-machine.mdx │ │ ├── magic-link.mdx │ │ ├── management-api.mdx │ │ ├── mfa.mdx │ │ ├── multi-tenancy.mdx │ │ ├── oauth-2.0-grant.mdx │ │ ├── oauth-2.0.mdx │ │ ├── oauth-2.1.mdx │ │ ├── offline-access.mdx │ │ ├── opaque-token.mdx │ │ ├── openid-connect-discovery.mdx │ │ ├── openid-connect.mdx │ │ ├── otp.mdx │ │ ├── passkey.mdx │ │ ├── passwordless.mdx │ │ ├── pkce.mdx │ │ ├── protected-resource-metadata.mdx │ │ ├── rbac.mdx │ │ ├── redirect-uri.mdx │ │ ├── refresh-token.mdx │ │ ├── resource-indicator.mdx │ │ ├── resource-owner.mdx │ │ ├── resource-server.mdx │ │ ├── role.mdx │ │ ├── saml.mdx │ │ ├── scope.mdx │ │ ├── service-provider.mdx │ │ ├── signing-key.mdx │ │ ├── single-sign-on.mdx │ │ ├── token-introspection.mdx │ │ ├── token-request.mdx │ │ ├── totp.mdx │ │ ├── userinfo-endpoint.mdx │ │ ├── webauthn.mdx │ │ ├── webhook.mdx │ │ └── xacml.mdx │ │ ├── pt-pt │ │ ├── abac.mdx │ │ ├── access-control.mdx │ │ ├── access-token.mdx │ │ ├── api-key.mdx │ │ ├── audience.mdx │ │ ├── auth.mdx │ │ ├── authentication-request.mdx │ │ ├── authentication.mdx │ │ ├── authorization-code-flow.mdx │ │ ├── authorization-request.mdx │ │ ├── authorization-server-metadata.mdx │ │ ├── authorization-server.mdx │ │ ├── authorization.mdx │ │ ├── backup code.mdx │ │ ├── claim.mdx │ │ ├── client-credentials-flow.mdx │ │ ├── client.mdx │ │ ├── csprng.mdx │ │ ├── csrf.mdx │ │ ├── device-flow.mdx │ │ ├── enterprise-sso.mdx │ │ ├── hybrid-flow.mdx │ │ ├── iam.mdx │ │ ├── id-token.mdx │ │ ├── identity-provider.mdx │ │ ├── implicit-flow.mdx │ │ ├── jit-provisioning.mdx │ │ ├── jwe.mdx │ │ ├── jwk.mdx │ │ ├── jws.mdx │ │ ├── jwt.mdx │ │ ├── machine-to-machine.mdx │ │ ├── magic-link.mdx │ │ ├── management-api.mdx │ │ ├── mfa.mdx │ │ ├── multi-tenancy.mdx │ │ ├── oauth-2.0-grant.mdx │ │ ├── oauth-2.0.mdx │ │ ├── oauth-2.1.mdx │ │ ├── offline-access.mdx │ │ ├── opaque-token.mdx │ │ ├── openid-connect-discovery.mdx │ │ ├── openid-connect.mdx │ │ ├── otp.mdx │ │ ├── passkey.mdx │ │ ├── passwordless.mdx │ │ ├── pkce.mdx │ │ ├── protected-resource-metadata.mdx │ │ ├── rbac.mdx │ │ ├── redirect-uri.mdx │ │ ├── refresh-token.mdx │ │ ├── resource-indicator.mdx │ │ ├── resource-owner.mdx │ │ ├── resource-server.mdx │ │ ├── role.mdx │ │ ├── saml.mdx │ │ ├── scope.mdx │ │ ├── service-provider.mdx │ │ ├── signing-key.mdx │ │ ├── single-sign-on.mdx │ │ ├── token-introspection.mdx │ │ ├── token-request.mdx │ │ ├── totp.mdx │ │ ├── userinfo-endpoint.mdx │ │ ├── webauthn.mdx │ │ ├── webhook.mdx │ │ └── xacml.mdx │ │ ├── zh-Hant │ │ ├── abac.mdx │ │ ├── access-control.mdx │ │ ├── access-token.mdx │ │ ├── api-key.mdx │ │ ├── audience.mdx │ │ ├── auth.mdx │ │ ├── authentication-request.mdx │ │ ├── authentication.mdx │ │ ├── authorization-code-flow.mdx │ │ ├── authorization-request.mdx │ │ ├── authorization-server-metadata.mdx │ │ ├── authorization-server.mdx │ │ ├── authorization.mdx │ │ ├── backup code.mdx │ │ ├── claim.mdx │ │ ├── client-credentials-flow.mdx │ │ ├── client.mdx │ │ ├── csprng.mdx │ │ ├── csrf.mdx │ │ ├── device-flow.mdx │ │ ├── enterprise-sso.mdx │ │ ├── hybrid-flow.mdx │ │ ├── iam.mdx │ │ ├── id-token.mdx │ │ ├── identity-provider.mdx │ │ ├── implicit-flow.mdx │ │ ├── jit-provisioning.mdx │ │ ├── jwe.mdx │ │ ├── jwk.mdx │ │ ├── jws.mdx │ │ ├── jwt.mdx │ │ ├── machine-to-machine.mdx │ │ ├── magic-link.mdx │ │ ├── management-api.mdx │ │ ├── mfa.mdx │ │ ├── multi-tenancy.mdx │ │ ├── oauth-2.0-grant.mdx │ │ ├── oauth-2.0.mdx │ │ ├── oauth-2.1.mdx │ │ ├── offline-access.mdx │ │ ├── opaque-token.mdx │ │ ├── openid-connect-discovery.mdx │ │ ├── openid-connect.mdx │ │ ├── otp.mdx │ │ ├── passkey.mdx │ │ ├── passwordless.mdx │ │ ├── pkce.mdx │ │ ├── protected-resource-metadata.mdx │ │ ├── rbac.mdx │ │ ├── redirect-uri.mdx │ │ ├── refresh-token.mdx │ │ ├── resource-indicator.mdx │ │ ├── resource-owner.mdx │ │ ├── resource-server.mdx │ │ ├── role.mdx │ │ ├── saml.mdx │ │ ├── scope.mdx │ │ ├── service-provider.mdx │ │ ├── signing-key.mdx │ │ ├── single-sign-on.mdx │ │ ├── token-introspection.mdx │ │ ├── token-request.mdx │ │ ├── totp.mdx │ │ ├── userinfo-endpoint.mdx │ │ ├── webauthn.mdx │ │ ├── webhook.mdx │ │ └── xacml.mdx │ │ └── zh │ │ ├── abac.mdx │ │ ├── access-control.mdx │ │ ├── access-token.mdx │ │ ├── api-key.mdx │ │ ├── audience.mdx │ │ ├── auth.mdx │ │ ├── authentication-request.mdx │ │ ├── authentication.mdx │ │ ├── authorization-code-flow.mdx │ │ ├── authorization-request.mdx │ │ ├── authorization-server-metadata.mdx │ │ ├── authorization-server.mdx │ │ ├── authorization.mdx │ │ ├── backup code.mdx │ │ ├── claim.mdx │ │ ├── client-credentials-flow.mdx │ │ ├── client.mdx │ │ ├── csprng.mdx │ │ ├── csrf.mdx │ │ ├── device-flow.mdx │ │ ├── enterprise-sso.mdx │ │ ├── hybrid-flow.mdx │ │ ├── iam.mdx │ │ ├── id-token.mdx │ │ ├── identity-provider.mdx │ │ ├── implicit-flow.mdx │ │ ├── jit-provisioning.mdx │ │ ├── jwe.mdx │ │ ├── jwk.mdx │ │ ├── jws.mdx │ │ ├── jwt.mdx │ │ ├── machine-to-machine.mdx │ │ ├── magic-link.mdx │ │ ├── management-api.mdx │ │ ├── mfa.mdx │ │ ├── multi-tenancy.mdx │ │ ├── oauth-2.0-grant.mdx │ │ ├── oauth-2.0.mdx │ │ ├── oauth-2.1.mdx │ │ ├── offline-access.mdx │ │ ├── opaque-token.mdx │ │ ├── openid-connect-discovery.mdx │ │ ├── openid-connect.mdx │ │ ├── otp.mdx │ │ ├── passkey.mdx │ │ ├── passwordless.mdx │ │ ├── pkce.mdx │ │ ├── protected-resource-metadata.mdx │ │ ├── rbac.mdx │ │ ├── redirect-uri.mdx │ │ ├── refresh-token.mdx │ │ ├── resource-indicator.mdx │ │ ├── resource-owner.mdx │ │ ├── resource-server.mdx │ │ ├── role.mdx │ │ ├── saml.mdx │ │ ├── scope.mdx │ │ ├── service-provider.mdx │ │ ├── signing-key.mdx │ │ ├── single-sign-on.mdx │ │ ├── token-introspection.mdx │ │ ├── token-request.mdx │ │ ├── totp.mdx │ │ ├── userinfo-endpoint.mdx │ │ ├── webauthn.mdx │ │ ├── webhook.mdx │ │ └── xacml.mdx ├── env.d.ts ├── icons │ ├── document.svg │ ├── external-link.svg │ ├── github.svg │ ├── hacker-news.svg │ ├── hyperlink.svg │ ├── linked-in.svg │ ├── logto-logo.svg │ ├── reddit.svg │ └── x.svg ├── layouts │ └── Layout.astro ├── mdx-components │ ├── Img.astro │ ├── Ref.astro │ ├── Resources.astro │ ├── SeeAlso.astro │ └── TextLink.astro ├── pages │ ├── 404.astro │ ├── [lang] │ │ └── [...slug] │ │ │ └── cover.png.ts │ ├── [slug].astro │ ├── index.astro │ └── robots.txt.ts ├── phrases │ ├── ar.ts │ ├── de.ts │ ├── en.ts │ ├── es.ts │ ├── fr.ts │ ├── index.ts │ ├── it.ts │ ├── ja.ts │ ├── ko.ts │ ├── nl.ts │ ├── pt-br.ts │ ├── pt-pt.ts │ ├── zh-hant.ts │ └── zh.ts └── utils │ ├── cover.ts │ ├── locale.test.ts │ ├── locale.ts │ ├── share.ts │ └── string.ts ├── translate.mjs ├── translate.openai.mjs ├── tsconfig.json ├── vitest.config.ts └── wrangler.toml /.github/PULL_REQUEST_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | 2 | ## Summary 3 | 4 | -------------------------------------------------------------------------------- /.github/workflows/deploy.yml: -------------------------------------------------------------------------------- 1 | name: Deploy to Cloudflare Pages 2 | on: [push] 3 | 4 | jobs: 5 | deploy: 6 | environment: cloudflare-pages 7 | runs-on: ubuntu-latest 8 | name: Deploy 9 | steps: 10 | - uses: actions/checkout@v4 11 | 12 | - name: Setup Node and pnpm 13 | uses: silverhand-io/actions-node-pnpm-run-steps@v5 14 | 15 | - name: Build 16 | run: pnpm build 17 | 18 | - name: Deploy 19 | uses: cloudflare/wrangler-action@v3 20 | with: 21 | apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }} 22 | command: pages deploy 23 | -------------------------------------------------------------------------------- /.github/workflows/main.yml: -------------------------------------------------------------------------------- 1 | name: Main jobs 2 | on: 3 | push: 4 | branches: 5 | - master 6 | pull_request: 7 | 8 | jobs: 9 | main: 10 | runs-on: ubuntu-latest 11 | steps: 12 | - uses: actions/checkout@v4 13 | 14 | - name: Setup Node and pnpm 15 | uses: silverhand-io/actions-node-pnpm-run-steps@v5 16 | 17 | - name: Build 18 | run: pnpm build 19 | 20 | - name: Test 21 | run: pnpm test 22 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | ############################ 2 | # OS X 3 | ############################ 4 | 5 | .DS_Store 6 | .AppleDouble 7 | .LSOverride 8 | Icon 9 | .Spotlight-V100 10 | .Trashes 11 | ._* 12 | 13 | 14 | ############################ 15 | # Linux 16 | ############################ 17 | 18 | *~ 19 | 20 | 21 | ############################ 22 | # Windows 23 | ############################ 24 | 25 | Thumbs.db 26 | ehthumbs.db 27 | Desktop.ini 28 | $RECYCLE.BIN/ 29 | *.cab 30 | *.msi 31 | *.msm 32 | *.msp 33 | 34 | 35 | ############################ 36 | # Packages 37 | ############################ 38 | 39 | *.7z 40 | *.csv 41 | *.dat 42 | *.dmg 43 | *.gz 44 | *.iso 45 | *.jar 46 | *.rar 47 | *.tar 48 | *.zip 49 | *.com 50 | *.class 51 | *.dll 52 | *.exe 53 | *.o 54 | *.seed 55 | *.so 56 | *.swo 57 | *.swp 58 | *.swn 59 | *.swm 60 | *.out 61 | *.pid 62 | 63 | 64 | ############################ 65 | # Logs and databases 66 | ############################ 67 | 68 | .tmp 69 | *.log 70 | *.sql 71 | *.sqlite 72 | *.sqlite3 73 | 74 | 75 | ############################ 76 | # Misc. 77 | ############################ 78 | 79 | *# 80 | ssl 81 | .idea 82 | nbproject 83 | .tsbuildinfo 84 | .eslintcache 85 | 86 | ############################ 87 | # Node.js 88 | ############################ 89 | 90 | lib-cov 91 | lcov.info 92 | pids 93 | logs 94 | results 95 | node_modules 96 | .node_history 97 | 98 | ############################ 99 | # Package managers 100 | ############################ 101 | 102 | .yarn/* 103 | !.yarn/cache 104 | !.yarn/unplugged 105 | !.yarn/patches 106 | !.yarn/releases 107 | !.yarn/sdks 108 | !.yarn/versions 109 | .pnp.* 110 | yarn-error.log 111 | 112 | ############################ 113 | # Tests 114 | ############################ 115 | 116 | coverage 117 | 118 | ############################ 119 | # Strapi 120 | ############################ 121 | 122 | .env 123 | .env.production 124 | license.txt 125 | exports 126 | .strapi 127 | dist 128 | build 129 | .strapi-updater.json 130 | .strapi-cloud.json 131 | 132 | # Astro 133 | .astro 134 | astro_tmp_pages_* 135 | .og-cache.json 136 | 137 | ############################ 138 | # VS Code 139 | ############################ 140 | .vscode 141 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 |

2 | 3 | 4 | 5 | 6 | Auth Wiki 7 | 8 | 9 |

10 | 11 | # Auth Wiki 12 | 13 | A comprehensive collection of articles, tutorials, and resources about authentication and authorization. Learn about OAuth 2.0, OpenID Connect, SAML, and more. 14 | 15 | ## Contributing 16 | 17 | We welcome contributions from everyone! Whether you’ve found a typo, want to suggest a new entry, or improve existing content, your help is appreciated. 18 | 19 | ### How to contribute 20 | 21 | 1. **Report issues**: If you spot any errors or have suggestions, please [create an issue](https://github.com/logto-io/auth-wiki/issues/new). 22 | 23 | 2. **Edit directly**: The content resides in [src/content](./src/content). To make changes: 24 | - Navigate to the desired file. 25 | - Click the **edit** button (pencil icon) in the top right corner. 26 | - Make your edits and submit a pull request. 27 | 28 | > [!Note] 29 | > Auth Wiki is a multilingual project. You can contribute to any language you're comfortable with, we'll take care of the rest. 30 | 31 | ### Running locally 32 | 33 | Auth Wiki uses PNPM and Astro. To preview your changes locally: 34 | 35 | ```bash 36 | pnpm install 37 | pnpm dev 38 | ``` 39 | 40 | ### Tips for contributors 41 | 42 | - Ensure your writing is clear and concise. 43 | - Maintain consistent formatting and adhere to the existing structure. 44 | - Reference credible sources where appropriate. 45 | -------------------------------------------------------------------------------- /astro.config.mjs: -------------------------------------------------------------------------------- 1 | import { defineConfig } from 'astro/config'; 2 | import rehypeMermaid from 'rehype-mermaid'; 3 | import { rehypeShiki } from '@astrojs/markdown-remark'; 4 | import sitemap from '@astrojs/sitemap'; 5 | import mdx from '@astrojs/mdx'; 6 | import icon from "astro-icon"; 7 | import remarkCustomHeaderId from 'remark-custom-header-id'; 8 | import { i18n, filterSitemapByDefaultLocale } from "astro-i18n-aut/integration"; 9 | 10 | export const defaultLocale = 'en'; 11 | export const locales = Object.freeze({ 12 | ar: 'ar', 13 | de: 'de', 14 | en: 'en', 15 | es: 'es', 16 | fr: 'fr', 17 | it: 'it', 18 | ko: 'ko', 19 | ja: 'ja', 20 | nl: 'nl', 21 | 'pt-br': 'pt-BR', 22 | 'pt-pt': 'pt-PT', 23 | zh: 'zh-Hans', 24 | // Astro doesn't maintain the case when generating file-based slugs, so we need to use the 25 | // lowercase version of the locale code as the key. 26 | // See: https://github.com/withastro/roadmap/pull/373#issuecomment-1332459000 27 | // See: https://github.com/withastro/roadmap/discussions/516 28 | 'zh-hant': 'zh-Hant', 29 | }); 30 | 31 | // https://astro.build/config 32 | export default defineConfig({ 33 | site: 'https://auth.wiki', 34 | build: { 35 | format: 'file', 36 | }, 37 | trailingSlash: 'never', 38 | markdown: { 39 | rehypePlugins: [ 40 | [rehypeMermaid, { dark: true, strategy: 'img-svg' }], 41 | [rehypeShiki, { themes: { light: 'one-light', dark: 'one-dark-pro' } }] 42 | ], 43 | remarkPlugins: [remarkCustomHeaderId], 44 | remarkRehype: { 45 | footnoteLabelTagName: 'span', 46 | }, 47 | syntaxHighlight: false 48 | }, 49 | integrations: [ 50 | i18n({ 51 | locales, 52 | defaultLocale, 53 | exclude: ['pages/**/*.ts'] 54 | }), 55 | mdx(), 56 | sitemap({ 57 | i18n: { 58 | locales, 59 | defaultLocale, 60 | }, 61 | filter: filterSitemapByDefaultLocale({ defaultLocale }), 62 | }), 63 | icon() 64 | ] 65 | }); 66 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "auth-wiki", 3 | "type": "module", 4 | "private": true, 5 | "version": "0.0.1", 6 | "scripts": { 7 | "prepare": "playwright install --with-deps chromium", 8 | "dev": "astro dev", 9 | "start": "astro dev", 10 | "build": "astro check && astro build", 11 | "build:dev": "astro check && SKIP_RESOURCE_FETCH=1 astro build", 12 | "test": "vitest", 13 | "preview": "astro preview", 14 | "astro": "astro", 15 | "wrangler": "wrangler", 16 | "translate": "node ./translate.mjs" 17 | }, 18 | "devDependencies": { 19 | "@astrojs/check": "^0.9.4", 20 | "@astrojs/markdown-remark": "^6.0.1", 21 | "@astrojs/mdx": "^3.1.9", 22 | "@astrojs/sitemap": "^3.2.1", 23 | "@astrolib/seo": "1.0.0-beta.8", 24 | "@vitest/coverage-v8": "3.1.1", 25 | "any-ascii": "^0.3.2", 26 | "arg": "^5.0.2", 27 | "astro": "^4.16.18", 28 | "astro-i18n-aut": "^0.7.0", 29 | "astro-icon": "^1.1.4", 30 | "commander": "^13.0.0", 31 | "dotenv": "^16.4.5", 32 | "https-proxy-agent": "^7.0.5", 33 | "listr2": "^8.2.5", 34 | "open-graph-scraper": "^6.8.2", 35 | "openai": "^4.71.0", 36 | "p-map": "^7.0.2", 37 | "picocolors": "^1.1.1", 38 | "playwright": "^1.48.2", 39 | "rehype-mermaid": "^3.0.0", 40 | "remark-custom-header-id": "^1.0.0", 41 | "typescript": "^5.5.4", 42 | "vitest": "3.1.1", 43 | "wrangler": "^3.99.0" 44 | }, 45 | "pnpm": { 46 | "overrides": { 47 | "@babel/helpers@<7.27.0": "^7.27.0", 48 | "axios@>=1.0.0 <1.8.2": "^1.8.2", 49 | "dompurify@<3.2.4": "^3.2.4", 50 | "esbuild@<0.25.0": "^0.25.0", 51 | "mermaid-isomorphic": "github:silverhand-io/mermaid-isomorphic#c081c30", 52 | "prismjs@<1.30.0": "^1.30.0", 53 | "undici@>=4.5.0 <5.28.5": "^5.28.5", 54 | "undici@>=6.0.0 <6.21.1": "^6.21.1", 55 | "vite": "^6.2.5" 56 | } 57 | } 58 | } 59 | -------------------------------------------------------------------------------- /public/47b9e55389f64921b44796a80c2538b4.txt: -------------------------------------------------------------------------------- 1 | 47b9e55389f64921b44796a80c2538b4 2 | -------------------------------------------------------------------------------- /public/apple-touch-icon.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/logto-io/auth-wiki/3fd7993ea1ae1fc3a043ac8163f07ee5d4af29fd/public/apple-touch-icon.png -------------------------------------------------------------------------------- /public/favicon-160x160.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/logto-io/auth-wiki/3fd7993ea1ae1fc3a043ac8163f07ee5d4af29fd/public/favicon-160x160.png -------------------------------------------------------------------------------- /public/favicon-16x16.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/logto-io/auth-wiki/3fd7993ea1ae1fc3a043ac8163f07ee5d4af29fd/public/favicon-16x16.png -------------------------------------------------------------------------------- /public/favicon-32x32.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/logto-io/auth-wiki/3fd7993ea1ae1fc3a043ac8163f07ee5d4af29fd/public/favicon-32x32.png -------------------------------------------------------------------------------- /public/logo.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 7 | 8 | 9 | 10 | 11 | 14 | 15 | 16 | 17 | 19 | 20 | 21 | 22 | 23 | 26 | 27 | 28 | 29 | 31 | 32 | 33 | 34 | 35 | 38 | 39 | 40 | 41 | -------------------------------------------------------------------------------- /renovate.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "https://docs.renovatebot.com/renovate-schema.json", 3 | "extends": [ 4 | "local>logto-io/.github:renovate-config" 5 | ] 6 | } 7 | -------------------------------------------------------------------------------- /src/assets/cover.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/logto-io/auth-wiki/3fd7993ea1ae1fc3a043ac8163f07ee5d4af29fd/src/assets/cover.png -------------------------------------------------------------------------------- /src/components/BackgroundBanner.astro: -------------------------------------------------------------------------------- 1 | --- 2 | import banner from "../assets/banner.svg"; 3 | --- 4 | 5 | 6 |
7 |
8 |
9 | Banner 10 |
11 | 12 | 73 | -------------------------------------------------------------------------------- /src/components/BackgroundCells.astro: -------------------------------------------------------------------------------- 1 | --- 2 | const opacityNumbers = [ 3 | 0, 0.4, 0.2, 0, 0.6, 0.6, 0.3, 0.7, 0.3, 0.3, 1, 1, 1, 0.5, 0.7, 0.4, 0.4, 4 | 0.4, 0.4, 0.4, 0.4, 1, 0.3, 5 | ]; 6 | 7 | type Props = { 8 | class?: string; 9 | }; 10 | 11 | const { class: className, ...rest } = Astro.props; 12 | --- 13 | 14 |
15 | {opacityNumbers.map((opacity) => )} 16 |
17 | 18 | 44 | -------------------------------------------------------------------------------- /src/components/ByLogto.astro: -------------------------------------------------------------------------------- 1 | --- 2 | import { Icon } from "astro-icon/components"; 3 | import { defaultLocale } from "astro-i18n-aut"; 4 | import { getLocaleFromUrl } from "../utils/locale"; 5 | 6 | const locale = getLocaleFromUrl(Astro.url); 7 | --- 8 | 9 | 16 | Designed by 17 | 18 | Logto 19 | 20 | 21 | 28 | -------------------------------------------------------------------------------- /src/components/FancyHr.astro: -------------------------------------------------------------------------------- 1 |
2 | 3 | 4 |
5 | 6 | 31 | -------------------------------------------------------------------------------- /src/components/Footer.astro: -------------------------------------------------------------------------------- 1 | --- 2 | import ByLogto from "./ByLogto.astro"; 3 | --- 4 | 5 | 8 | 9 | 25 | -------------------------------------------------------------------------------- /src/components/Logo.astro: -------------------------------------------------------------------------------- 1 | Logo 2 | Logo 3 | 4 | 26 | -------------------------------------------------------------------------------- /src/components/Share.astro: -------------------------------------------------------------------------------- 1 | --- 2 | import ShareButton from "../components/ShareButton.astro"; 3 | 4 | type Props = { 5 | title: string; 6 | shareText?: string; 7 | }; 8 | 9 | const { title, shareText } = Astro.props; 10 | --- 11 | 12 | 21 | 22 | 43 | -------------------------------------------------------------------------------- /src/components/ShareButton.astro: -------------------------------------------------------------------------------- 1 | --- 2 | import { Icon } from "astro-icon/components"; 3 | import { shareTitleMap, type buildShareUrlMap } from "../utils/share"; 4 | 5 | type Props = { 6 | /** 7 | * The type of share button to render. It must be a valid key of the `buildShareUrlMap` object 8 | * and it must can be loaded from the `astro-icon` package. 9 | * @see {@link https://astroicon.dev/} for more information. 10 | */ 11 | type: keyof typeof buildShareUrlMap; 12 | /** 13 | * The title of the page to share. 14 | */ 15 | title: string; 16 | }; 17 | 18 | const { type, title } = Astro.props; 19 | --- 20 | 21 | 22 | 25 | 26 | 27 | 44 | 45 | 68 | -------------------------------------------------------------------------------- /src/components/Tags.astro: -------------------------------------------------------------------------------- 1 | --- 2 | interface Props { 3 | data: string[] | null; 4 | } 5 | 6 | const { data } = Astro.props; 7 | --- 8 | 9 |
10 | {data?.map((tag) => {tag})} 11 |
12 | 13 | 29 | -------------------------------------------------------------------------------- /src/components/Topbar.astro: -------------------------------------------------------------------------------- 1 | --- 2 | import { Icon } from "astro-icon/components"; 3 | import Logo from "./Logo.astro"; 4 | import ByLogto from "./ByLogto.astro"; 5 | import { defaultLocale } from "astro-i18n-aut"; 6 | import LanguageSelector from "./LanguageSelector.astro"; 7 | import { getLocaleFromUrl } from "../utils/locale"; 8 | 9 | const locale = getLocaleFromUrl(Astro.url); 10 | --- 11 | 12 |
13 | 18 | 19 | 20 |
21 | 27 | 28 | GitHub 29 | 30 | 31 | 32 |
33 |
34 | 70 | -------------------------------------------------------------------------------- /src/content/config.ts: -------------------------------------------------------------------------------- 1 | import { defineCollection, z } from 'astro:content'; 2 | 3 | const termsCollection = defineCollection({ 4 | type: 'content', 5 | schema: z.object({ 6 | title: z.string(), 7 | description: z.string(), 8 | tags: z.array(z.string()), 9 | }), 10 | }); 11 | 12 | export const collections = { 13 | 'terms': termsCollection, 14 | }; 15 | -------------------------------------------------------------------------------- /src/content/terms/ar/auth.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: توضيح (Auth, إزالة الغموض) 3 | tags: [authentication, authorization] 4 | description: غالبًا ما يُستخدم مصطلح "auth" كاختصار لعملية المصادقة (authentication) أو التفويض (authorization). هذه المفاهيم ذات صلة ولكنها مختلفة تمامًا. 5 | --- 6 | 7 | ## توضيح (Auth) 8 | 9 | هذه الصفحة توضيح لمصطلح "auth". غالبًا ما يُستخدم كاختصار لـ: 10 | 11 | - : عملية التحقق من ملكية الهوية (مثل المستخدم أو الخدمة). يجيب عن السؤال "ما هي الهوية التي تملكها؟" 12 | - : عملية تحديد ما هي الإجراءات التي يمكن للهوية تنفيذها على المورد. يجيب عن السؤال "ماذا يمكنك أن تفعل؟" 13 | 14 | > [!Note] 15 | > أحيانًا، تُعرف المصادقة (authentication) والتفويض (authorization) بـ "AuthN" و "AuthZ" على التوالي. 16 | 17 | هذان المفهومان كلاهما ضروري في مجال ، ولكنهما مختلفان أساسًا. لنرى مثالاً: تطبيق الويب MyStorage لديه القدرة على تحميل الملفات والاتصال بـ Google Drive. ستكون عملية المستخدم النموذجية كما يلي: 18 | 19 | ```mermaid 20 | sequenceDiagram 21 | participant User 22 | participant MyStorage 23 | participant Google 24 | autonumber 25 | 26 | User->>MyStorage: تسجيل الدخول إلى MyStorage 27 | MyStorage->>User: مرحبًا، User! 28 | User->>MyStorage: انقر على "الاتصال بـ Google Drive" 29 | MyStorage->>Google: تحويل إلى Google
مع طلب تفويض (authorization request) 30 | Google->>User: مطالبة المستخدم بتسجيل الدخول 31 | User->>Google: تسجيل الدخول إلى Google 32 | Google->>User: طلب إذن للوصول إلى Google Drive 33 | User->>Google: منح الوصول إلى MyStorage 34 | Google->>MyStorage: إعادة التوجيه إلى MyStorage
مع بيانات التفويض (مثل access token) 35 | MyStorage->>Google: الوصول إلى Google Drive الخاص بالمستخدم باستخدام access token 36 | ``` 37 | 38 | في هذا التسلسل، يقوم المستخدم بخطوتين من المصادقة (authentication): واحدة مع MyStorage (الخطوة 1) وأخرى مع Google (الخطوة 6)؛ وخطوة واحدة من التفويض (authorization): منح الوصول إلى Google Drive (الخطوة 8). 39 | 40 | ## ماذا تقصد؟ 41 | 42 | عندما ترى مصطلح "auth"، من المهم توضيح ما إذا كان يشير إلى المصادقة (authentication) أو التفويض (authorization)؛ وإلا، قد تتوقع أن يتم تغطية كلا العمليتين (تمامًا كما تفعل هذه الصفحة). 43 | 44 | 45 | -------------------------------------------------------------------------------- /src/content/terms/ar/otp.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: كلمة مرور لمرة واحدة (One-time password, OTP) 3 | tags: [authentication] 4 | description: كلمة المرور لمرة واحدة (OTP) هي رمز فريد ومؤقت يُستخدم لعملية واحدة أو جلسة تسجيل دخول واحدة. 5 | --- 6 | 7 | ## ما هو OTP؟ 8 | 9 | كلمة المرور لمرة واحدة (OTP) هي رمز فريد ومؤقت يُستخدم لعملية واحدة أو جلسة تسجيل دخول واحدة. على عكس كلمات المرور التقليدية، التي تكون ثابتة وتبقى كما هي حتى يغيرها المستخدم، فإن OTP ديناميكية وتنتهي صلاحيتها بسرعة بعد إصدارها، وعادةً ما تنتهي خلال بضع دقائق. هذه الطبيعة الديناميكية تجعل OTP أكثر أمانًا بشكل كبير لأنهم يقللون بدرجة كبيرة من خطر الوصول غير المصرح به حتى إذا تم اعتراض OTP من قبل أطراف خبيثة. 10 | 11 | عادةً ما يتم إنشاء OTP باستخدام خوارزميات تعتمد على مزامنة الوقت أو الحسابات الرياضية، مما يضمن أن كل رمز فريد وغير متوقع. غالبًا ما يتلقى المستخدمون OTP عبر الرسائل القصيرة SMS، البريد الإلكتروني، التطبيقات المحمولة، أو الرموز المادية. 12 | 13 | ## ما هي حالات الاستخدام الشائعة لكلمة المرور لمرة واحدة (OTP)؟ 14 | 15 | فيما يلي بعض الاستخدامات الرئيسية لكلمات المرور لمرة واحدة: 16 | 17 | ### تسجيل الدخول بدون كلمة مرور 18 | 19 | تقدم العديد من المواقع والتطبيقات الآن خيارات تسجيل الدخول بدون كلمة مرور لتعزيز الأمان وراحة المستخدم. يمكن للمستخدمين طلب OTP مرسل إلى رقم هاتفهم المحمول المسجل أو بريدهم الإلكتروني للتحقق من هويتهم، دون الحاجة إلى تذكر كلمات مرور معقدة. هذا النهج لا يبسط فقط عملية تسجيل الدخول ولكنه يقلل أيضًا من خطر الاختراقات المتعلقة بكلمة المرور. 20 | 21 | ### استعادة كلمة المرور 22 | 23 | في الحالات التي ينسى فيها المستخدمون كلمات المرور الخاصة بهم، تخدم OTP كوسيلة آمنة لاستعادة الحساب. يمكن للمستخدمين طلب OTP، الذي يتم إرساله إلى بريدهم الإلكتروني أو رقم هاتفهم المسجل، للتحقق من هويتهم قبل إعادة تعيين كلمة المرور الخاصة بهم. تساعد هذه العملية في ضمان أن المالك الشرعي للحساب هو الوحيد الذي يمكنه إجراء الاستعادة. 24 | 25 | ### المصادقة متعددة العوامل (MFA) 26 | 27 | تعد OTP جزءًا حيويًا من المصادقة متعددة العوامل (MFA)، التي تجمع بين شيء يعرفه المستخدم (مثل كلمة المرور) مع شيء لديه المستخدم (مثل جهاز محمول). بعد إدخال كلمة المرور الأساسية، يتلقى المستخدمون OTP التي يجب عليهم إدخالها للوصول. هذه الطبقة الإضافية من الأمان تقلل بشكل كبير من احتمالية الوصول غير المصرح به، حتى إذا تم اختراق كلمة المرور الأساسية. 28 | 29 | ### تأكيد العملية الحساسة 30 | 31 | بالنسبة للأنشطة التي تتضمن بيانات حساسة أو عمليات كبيرة، مثل الخدمات المصرفية عبر الإنترنت أو إجراء عمليات شراء ذات قيمة عالية، تخدم OTP كإجراء أمني لتأكيد موافقة المستخدم. قبل إكمال هذه الإجراءات، يتم إرسال OTP إلى طريقة الاتصال المسجلة للمستخدم، والتي يجب إدخالها لإتمام العملية. يضمن ذلك أنه حتى إذا حصل شخص ما على وصول إلى حساب المستخدم، فلن يتمكن من تنفيذ إجراءات حاسمة بدون OTP. 32 | 33 | 34 | -------------------------------------------------------------------------------- /src/content/terms/ar/role.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: دور (Role) 3 | tags: [authorization] 4 | description: الدور هو مفهوم أساسي في أنظمة التحكم في الوصول المستندة إلى الأدوار (RBAC)، ويمثل مجموعة من الأذونات التي تحدد ما يمكن للمستخدمين القيام به، مما يوفر طريقة فعالة لإدارة وتعيين حقوق الوصول للمستخدمين. 5 | --- 6 | 7 | ## دور (Role) 8 | 9 | الدور هو أحد المكونات الأساسية في . يعمل كحاوية للأذونات التي يمكن تعيينها للمستخدمين، ويعمل كوسيط بين المستخدمين وحقوق الوصول الخاصة بهم. 10 | 11 | ```mermaid 12 | graph LR 13 | المستخدمون 14 | -->|معين إلى| الأدوار 15 | -->|بما في ذلك| الأذونات 16 | ``` 17 | 18 | تحتوي بنية الدور النموذجية على اسم ومجموعة من الأذونات: 19 | 20 | ```typescript 21 | const role = { 22 | name: 'order_admin', 23 | permissions: [ 24 | 'read:orders', // عرض تفاصيل الطلب 25 | 'write:orders', // تعديل الطلبات 26 | 'read:products' // عرض المنتجات 27 | ] 28 | } 29 | ``` 30 | 31 | > [!Note] 32 | > تُستخدم الأدوار بشكل أساسي لإدارة الأذونات. لتنفيذ التحكم في الوصول، يُوصى بفحص الأذونات مباشرة بدلاً من الأدوار. راجع لمزيد من المعلومات. 33 | 34 | -------------------------------------------------------------------------------- /src/content/terms/ar/service-provider.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: مزود الخدمة (Service Provider, SP) 3 | tags: [authentication, authorization] 4 | description: مزود الخدمة (Service Provider, SP) هو تطبيق أو خدمة تعتمد على مزود الهوية (Identity Provider - IdP) للمصادقة (authentication) والتفويض (authorization). 5 | --- 6 | 7 | ## ما هو مزود الخدمة (Service Provider, SP)؟ 8 | 9 | في مجال ، يُعتبر مزود الخدمة (SP) (أو **الطرف المعتمد** في سياق ) تطبيقًا أو خدمة تعتمد على من أجل المصادقة (authentication) والتفويض (authorization). يتولى مسؤولية توفير الخدمات للمستخدمين وتطبيق سياسات بناءً على الرموز المميزة (tokens) التي يصدرها مزود الهوية. 10 | 11 | ```mermaid 12 | graph LR 13 | IdP[مزود الهوية] 14 | SP["مزود الخدمة
(تطبيق، خدمة، API)"] 15 | IdP -->|يوثق المستخدمين| SP 16 | IdP -->|يصدر رموزاً| SP 17 | IdP -->|يوفر معلومات المستخدم| SP 18 | ``` 19 | 20 | ## معايير مزود الخدمة 21 | 22 | لا توجد معايير صارمة لمزودي الخدمة، حيث يمكن أن يكونوا أي نوع من التطبيقات أو الخدمات التي تتطلب إدارة الهوية. ومع ذلك، فإن مزودي الخدمة يتبعون غالبًا المعايير التي يضعها مزود الهوية الذي يعتمدون عليه. على سبيل المثال، إذا كان مزود الهوية يدعم ، فإن مزود الخدمة سيستخدم عادةً OIDC للمصادقة (authentication) والتفويض (authorization). 23 | 24 | ## هيكلية مزود الخدمة 25 | 26 | المصطلح "مزود الخدمة" لا يحدد بنية معينة أو تنفيذًا خاصًا. وعادةً ما يحتاج مزودو الخدمة إلى التسجيل لدى مزود الهوية لإقامة الثقة وتمكين الاتصال الآمن. عادةً ما تتضمن عملية التسجيل تبادل بيانات التعريف وبيانات اعتماد العميل. 27 | 28 | على سبيل المثال، في سياق OpenID Connect، تتضمن بيانات مزود الخدمة عادةً: 29 | 30 | - **معرف العميل**: معرف فريد لمزود الخدمة. 31 | - **سر العميل**: سر مشترك يستخدم لمصادقة مزود الخدمة. 32 | - **عناوين URI لإعادة التوجيه**: العناوين التي سيعيد إليها مزود الهوية المستخدمين بعد المصادقة (authentication) والتفويض (authorization). 33 | 34 | بمجرد التسجيل، يمكن لمزود الخدمة بدء عملية عن طريق إعادة توجيه المستخدمين إلى نقطة النهاية المحددة لمزود الهوية. 35 | 36 | عندما يتم بناء مزودي الخدمة لحالات استخدام غير تفاعلية، يتم الإشارة إليهم عادةً كـ عملاء يحتاجون إلى اتصال . 37 | 38 | 39 | 40 | 47 | -------------------------------------------------------------------------------- /src/content/terms/ar/token-introspection.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: تفتيش الرمز المميز (Token introspection) 3 | tags: [oauth 2.0, oidc] 4 | description: تفتيش الرمز المميز (Token introspection) هو امتداد لـ OAuth 2.0 يتيح للعملاء استعلام خادم التفويض للتحقق من صحة الرموز المميزة واسترداد البيانات الوصفية الخاصة بها. 5 | --- 6 | 7 | ## ما هو تفتيش الرمز المميز (Token introspection)؟ 8 | 9 | تفتيش الرمز المميز (Token introspection) هو امتداد لـ OAuth 2.0 يعرف في [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662) الذي يتيح لـ العملاء (clients) استعلام للتحقق من صحة الرموز المميزة واسترداد البيانات الوصفية الخاصة بها. يكون هذا الامتداد مفيدًا عندما: 10 | 11 | - يرغب العميل في التحقق من صحة الرمز المميز في الوقت الفعلي. 12 | - يكون الرمز المميز غير شفاف (opaque) (غير محتوٍ ذاتيًا) ويتطلب من خادم التفويض التحقق منه. 13 | 14 | ## كيف يعمل تفتيش الرمز المميز (Token introspection)؟ 15 | 16 | إليك مثال غير معياري لطلب تفتيش رمز مميز: 17 | 18 | ```http 19 | POST /introspect HTTP/1.1 20 | Host: authorization-server.example.com 21 | Content-Type: application/x-www-form-urlencoded 22 | 23 | token=random-token-value 24 | &token_type_hint=access_token 25 | ``` 26 | 27 | المعامل `token_type_hint` اختياري ويجب تحديده لنوع الرمز المميز الذي يتم التفتيش عنه. إذا كان الرمز المميز صحيحًا، فإن خادم التفويض يستجيب بالبيانات الوصفية الخاصة بالرمز: 28 | 29 | ```http 30 | HTTP/1.1 200 OK 31 | Content-Type: application/json 32 | 33 | { 34 | "active": true, 35 | "scope": "read write", 36 | "client_id": "client-id", 37 | "username": "johndoe", 38 | "token_type": "Bearer", 39 | "exp": 1634020800, 40 | "iat": 1634017200 41 | } 42 | ``` 43 | 44 | من الجدير بالذكر أن ليس كل خوادم التفويض تدعم تفتيش الرمز المميز وليس كل الرموز قابلة للتفتيش. قد يحد من استخدام تفتيش الرمز المميز بناءً على عوامل مختلفة، على سبيل المثال، قد لا تدعم بعض خوادم التفويض التفتيش لـ JWTs. 45 | 46 | ### المعاملات الرئيسية في طلب تفتيش الرمز المميز 47 | 48 | إليك معاملتين رئيسيتين في طلب تفتيش الرمز المميز: 49 | 50 | - **`token`**: الرمز المميز الذي سيتم تفتيشه. 51 | - **`token_type_hint`**: نوع الرمز المميز الذي يتم التفتيش عنه. يمكن أن يكون `access_token` أو `refresh_token`. 52 | 53 | 54 | 55 | -------------------------------------------------------------------------------- /src/content/terms/ar/totp.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: كلمة مرور لمرة واحدة تعتمد على الوقت (Time-based one-time password, TOTP) 3 | tags: [authentication] 4 | description: كلمة مرور لمرة واحدة تعتمد على الوقت (TOTP) هي رمز مؤقت وفريد يتم إنشاؤه بواسطة خوارزمية تستخدم الوقت الحالي كعامل رئيسي. 5 | --- 6 | 7 | ## ما هو TOTP؟ 8 | 9 | كلمة مرور لمرة واحدة تعتمد على الوقت (TOTP) هي رمز مؤقت وفريد يتم إنشاؤه بواسطة خوارزمية تستخدم الوقت الحالي كعامل رئيسي. مشابهًا لأي عام، يتم استخدام TOTP مرة واحدة فقط، ولكنه يمتلك عمرًا ثابتًا يتراوح عادة بين 30 إلى 60 ثانية. وعند انتهاء صلاحية الرمز، يتم إنشاء رمز جديد تلقائيًا. 10 | 11 | يتم تعريف معيار TOTP من قبل فريق عمل هندسة الإنترنت (IETF) تحت [RFC 6238](https://datatracker.ietf.org/doc/html/rfc6238)، ويُعتمد بشكل واسع في أنظمة المصادقة الثنائية (2FA) وأنظمة المصادقة متعددة العوامل (MFA). نظرًا لأن TOTPs يعتمد على الوقت المتزامن بين العميل (جهاز المستخدم) والخادم، فإنها توفر مستوى عالٍ من الأمان ومن الصعب التنبؤ بها أو إعادة استخدامها. 12 | 13 | ## كيف يعمل TOTP 14 | 15 | يشمل إنشاء TOTP الخطوات التالية: 16 | 17 | 1. المفتاح السري المشترك: خلال الإعداد الأولي، يتم إنشاء مفتاح سري مشترك وتخزينه بأمان على كل من العميل والخادم. يتم عادة تشفير هذا المفتاح كرمز QR يقوم المستخدمون بمسحه باستخدام تطبيق المصادقة. 18 | 2. فترات زمنية: يتم تقسيم الوقت الحالي إلى فترات ثابتة، عادة ما تكون 30 ثانية. 19 | 3. تطبيق الخوارزمية: يتم إدخال المفتاح السري المشترك والطابع الزمني الحالي في خوارزمية قائمة على التشفير (غالبًا HMAC-SHA1) لإنتاج رمز رقمي فريد. 20 | 4. المزامنة: يولد كل من العميل والخادم الرمز بشكل مستقل باستخدام نفس المفتاح السري المشترك والطابع الزمني الحالي. يطابق الرموز فقط إذا كان كلاهما في تزامن. 21 | 5. التحقق: عندما يقوم المستخدم بتسجيل الدخول أو إجراء معاملة حرجة، يدخل TOTP المعروض على تطبيق المصادقة الخاص به. يقوم الخادم بعد ذلك بمقارنته مع TOTP الذي تم إنشاؤه داخليًا للتأكد من صحته. 22 | 23 | ## متى يُستخدم TOTP 24 | 25 | في معظم الحالات، يوصى باستخدام OTP العادي، ولكن في الحالات التي يتعذر فيها "تشغيل" رمز مرور جديد، يوصى باستخدام TOTP. 26 | 27 | - مثال على TOTP: تطبيق المصادقة 28 | - مثال على OTP: البريد الإلكتروني، الرسائل القصيرة 29 | 30 | ## ما الفرق بين OTP و TOTP؟ 31 | 32 | الفرق الرئيسي هو أن TOTP يعتمد على الوقت، لذا فهو مناسب عندما لا يكون الجهاز متصلاً بالخادم. يمكن للخادم بسهولة إرسال رمز مرور جديد إلى عنوان بريد إلكتروني أو رقم هاتف، لكن ذلك يتطلب أن يكون البريد الإلكتروني أو الهاتف متصلًا بالإنترنت. ومع ذلك، يمكن لتطبيق المصادقة أن يبقى غير متصل ويستخدم "الوقت" للتحقق من صحة رمز المرور. 33 | 34 | 35 | -------------------------------------------------------------------------------- /src/content/terms/de/auth.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Auth (Begriffserklärung) 3 | tags: [authentifizierung, autorisierung] 4 | description: Der Begriff "auth" wird oft als Abkürzung für Authentifizierung (authentication) oder Autorisierung (authorization) verwendet. Diese Konzepte sind miteinander verwandt, aber grundlegend unterschiedlich. 5 | --- 6 | 7 | ## Auth 8 | 9 | Diese Seite ist eine Begriffserklärung für den Begriff "auth". Es wird oft als Abkürzung für verwendet: 10 | 11 | - : Der Prozess der Überprüfung der Identitätszugehörigkeit (z.B. eines Benutzers oder Dienstes). Er beantwortet die Frage "Welche Identität besitzt du?" 12 | - : Der Prozess der Bestimmung, welche Aktionen eine Identität auf einer Ressource ausführen kann. Es beantwortet die Frage "Was kannst du tun?" 13 | 14 | > [!Note] 15 | > Manchmal werden Authentifizierung (Authentication) und Autorisierung (Authorization) als "AuthN" und "AuthZ" bezeichnet. 16 | 17 | Diese beiden Konzepte sind im Bereich unerlässlich, aber sie sind grundlegend unterschiedlich. Schauen wir uns ein Beispiel an: Eine Webanwendung MyStorage hat die Fähigkeit, Dateien hochzuladen und sich mit Google Drive zu verbinden. Ein typischer Benutzerfluss sieht folgendermaßen aus: 18 | 19 | ```mermaid 20 | sequenceDiagram 21 | participant Benutzer 22 | participant MyStorage 23 | participant Google 24 | autonumber 25 | 26 | Benutzer->>MyStorage: Anmelden bei MyStorage 27 | MyStorage->>Benutzer: Willkommen, Benutzer! 28 | Benutzer->>MyStorage: Klick auf "Google Drive verbinden" 29 | MyStorage->>Google: Weiterleitung an Google
mit Autorisierungsanfrage 30 | Google->>Benutzer: Aufforderung zur Anmeldung 31 | Benutzer->>Google: Anmeldung bei Google 32 | Google->>Benutzer: Bitte um Erlaubnis, auf Google Drive zuzugreifen 33 | Benutzer->>Google: Zugriff auf MyStorage gewähren 34 | Google->>MyStorage: Weiterleitung an MyStorage
mit Autorisierungsdaten (z.B. Zugriffstoken (access token)) 35 | MyStorage->>Google: Zugriff auf das Google Drive des Benutzers mit dem Zugriffstoken 36 | ``` 37 | 38 | In diesem Ablauf führt der Benutzer zwei Authentifizierungsschritte durch: einen bei MyStorage (Schritt 1) und einen anderen bei Google (Schritt 6); und einen Autorisierungsschritt: die Gewährung des Zugriffs auf Google Drive (Schritt 8). 39 | 40 | ## Was meinst du? 41 | 42 | Wenn du den Begriff "auth" siehst, ist es wichtig zu klären, ob er sich auf Authentifizierung (authentication) oder Autorisierung (authorization) bezieht; andernfalls könnte man erwarten, dass beide Prozesse abgedeckt werden (so wie es diese Website tut). 43 | 44 | -------------------------------------------------------------------------------- /src/content/terms/de/role.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Rolle 3 | tags: [authorization] 4 | description: Eine Rolle ist ein Kernkonzept in rollenbasierten Zugriffskontrollsystemen (RBAC), das eine Sammlung von Berechtigungen darstellt, die definiert, welche Aktionen Benutzer ausführen können, und bietet eine effiziente Möglichkeit, Zugriffsrechte für Benutzer zu verwalten und zuzuweisen. 5 | --- 6 | 7 | ## Rolle 8 | 9 | Eine Rolle ist eine der Kernkomponenten in . Sie dient als Container für Berechtigungen, die Benutzern zugewiesen werden können, und fungiert als Vermittler zwischen Benutzern und ihren Zugriffsrechten. 10 | 11 | ```mermaid 12 | graph LR 13 | Benutzer 14 | -->|zugewiesen zu| Rollen 15 | -->|einschließlich| Berechtigungen 16 | ``` 17 | 18 | Eine typische Rollenstruktur enthält einen Namen und eine Reihe von Berechtigungen: 19 | 20 | ```typescript 21 | const role = { 22 | name: 'order_admin', 23 | permissions: [ 24 | 'read:orders', // Bestelldetails anzeigen 25 | 'write:orders', // Bestellungen bearbeiten 26 | 'read:products' // Produkte anzeigen 27 | ] 28 | } 29 | ``` 30 | 31 | > [!Note] 32 | > Rollen werden hauptsächlich für das Berechtigungsmanagement verwendet. Für die Implementierung der Zugriffskontrolle wird empfohlen, Berechtigungen direkt zu überprüfen, anstatt Rollen. Siehe für weitere Informationen. 33 | 34 | -------------------------------------------------------------------------------- /src/content/terms/de/token-introspection.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Tokenintrospektion (Token introspection) 3 | tags: [oauth 2.0, oidc] 4 | description: Tokenintrospektion ist eine OAuth 2.0-Erweiterung, die es Clients ermöglicht, den Autorisierungsserver abzufragen, um Zugriffstoken zu validieren und Metadaten darüber abzurufen. 5 | --- 6 | 7 | ## Was ist Tokenintrospektion? 8 | 9 | Tokenintrospektion ist eine OAuth 2.0-Erweiterung, definiert in [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662), die es Clients ermöglicht, den abzufragen, um Zugriffstoken zu validieren und Metadaten darüber abzurufen. Diese Erweiterung ist nützlich, wenn: 10 | 11 | - Der Client die Gültigkeit eines Zugriffstokens in Echtzeit überprüfen möchte. 12 | - Das Zugriffstoken opak (nicht selbst-enthaltend) ist und der Autorisierungsserver es validieren muss. 13 | 14 | ## Wie funktioniert die Tokenintrospektion? 15 | 16 | Hier ist ein nicht normatives Beispiel für eine Tokenintrospektionsanfrage: 17 | 18 | ```http 19 | POST /introspect HTTP/1.1 20 | Host: authorization-server.example.com 21 | Content-Type: application/x-www-form-urlencoded 22 | 23 | token=random-token-value 24 | &token_type_hint=access_token 25 | ``` 26 | 27 | Der Parameter `token_type_hint` ist optional und sollte auf den Typ des introspektierten Tokens gesetzt werden. Wenn das Zugriffstoken gültig ist, antwortet der Autorisierungsserver mit den Metadaten des Tokens: 28 | 29 | ```http 30 | HTTP/1.1 200 OK 31 | Content-Type: application/json 32 | 33 | { 34 | "active": true, 35 | "scope": "read write", 36 | "client_id": "client-id", 37 | "username": "johndoe", 38 | "token_type": "Bearer", 39 | "exp": 1634020800, 40 | "iat": 1634017200 41 | } 42 | ``` 43 | 44 | Es ist erwähnenswert, dass nicht alle Autorisierungsserver die Tokenintrospektion unterstützen und nicht alle Tokens introspektierbar sind. Der kann die Nutzung der Tokenintrospektion aus verschiedenen Gründen einschränken. Beispielsweise unterstützen einige Autorisierungsserver möglicherweise keine Introspektion für JWTs. 45 | 46 | ### Wichtige Parameter in einer Tokenintrospektionsanfrage 47 | 48 | Hier sind zwei wichtige Parameter in einer Tokenintrospektionsanfrage: 49 | 50 | - **`token`**: Das zu introspektierende Token. 51 | - **`token_type_hint`**: Der Typ des introspektierten Tokens. Es kann `access_token` oder `refresh_token` sein. 52 | 53 | 54 | 55 | 61 | -------------------------------------------------------------------------------- /src/content/terms/en/auth.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Auth (disambiguation) 3 | tags: [authentication, authorization] 4 | description: The term "auth" is often used as an abbreviation for authentication or authorization. These concepts are related but fundamentally different. 5 | --- 6 | 7 | ## Auth 8 | 9 | This page is a disambiguation for the term "auth". It is often used as an abbreviation for: 10 | 11 | - : The process of verifying the identity ownership (e.g., user or service). It answers the question "Which identity do you own?" 12 | - : The process of determining what actions an identity can perform on a resource. It answers the question "What can you do?" 13 | 14 | > [!Note] 15 | > Sometimes, authentication and authorization are referred to as "AuthN" and "AuthZ", respectively. 16 | 17 | These two concepts are both essential in the realm, but they are fundamentally different. Let's see an example: An web application MyStorage have the capability to upload files and connect to Google Drive. A typical user flow would be: 18 | 19 | ```mermaid 20 | sequenceDiagram 21 | participant User 22 | participant MyStorage 23 | participant Google 24 | autonumber 25 | 26 | User->>MyStorage: Sign in to MyStorage 27 | MyStorage->>User: Welcome, User! 28 | User->>MyStorage: Click "Connect Google Drive" 29 | MyStorage->>Google: Redirect to Google
with authorization request 30 | Google->>User: Prompt the user to sign in 31 | User->>Google: Sign in to Google 32 | Google->>User: Ask for permission to access Google Drive 33 | User->>Google: Grant access to MyStorage 34 | Google->>MyStorage: Redirect to MyStorage
with authorization data (e.g., access token) 35 | MyStorage->>Google: Access user's Google Drive using the access token 36 | ``` 37 | 38 | In this flow, the user performs two authentication steps: one with MyStorage (step 1) and another with Google (step 6); and one authorization step: granting access to Google Drive (step 8). 39 | 40 | ## Which one do you mean? 41 | 42 | When you see the term "auth", it's important to clarify whether it's referring to authentication or authorization; otherwise, you might expect both processes to be covered (just like this website does). 43 | 44 | 45 | -------------------------------------------------------------------------------- /src/content/terms/en/role.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Role 3 | tags: [authorization] 4 | description: A role is a core concept in role-based access control (RBAC) systems, representing a collection of permissions that defines what actions users can perform, providing an efficient way to manage and assign access rights to users. 5 | --- 6 | 7 | ## Role 8 | 9 | A role is one of the core components in . It serves as a container for permissions that can be assigned to users, acting as an intermediary between users and their access rights. 10 | 11 | ```mermaid 12 | graph LR 13 | Users 14 | -->|assigned to| Roles 15 | -->|including| Permissions 16 | ``` 17 | 18 | A typical role structure contains a name and a set of permissions: 19 | 20 | ```typescript 21 | const role = { 22 | name: 'order_admin', 23 | permissions: [ 24 | 'read:orders', // View order details 25 | 'write:orders', // Edit orders 26 | 'read:products' // View products 27 | ] 28 | } 29 | ``` 30 | 31 | > [!Note] 32 | > Roles are primarily used for permission management. For access control implementation, it's recommended to check permissions directly rather than roles. See for more information. 33 | 34 | 35 | -------------------------------------------------------------------------------- /src/content/terms/en/token-introspection.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Token introspection 3 | tags: [oauth 2.0, oidc] 4 | description: Token introspection is an OAuth 2.0 extension that allows clients to query the authorization server to validate access tokens and retrieve metadata about them. 5 | --- 6 | 7 | ## What is token introspection? 8 | 9 | Token introspection is an OAuth 2.0 extension defined in [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662) that allows clients to query the to validate access tokens and retrieve metadata about them. This extension is useful when: 10 | 11 | - The client wants to verify the validity of an access token in real-time. 12 | - The access token is opaque (not self-contained) and requires the authorization server to validate it. 13 | 14 | ## How does token introspection work? 15 | 16 | Here's a non-normative example of a token introspection request: 17 | 18 | ```http 19 | POST /introspect HTTP/1.1 20 | Host: authorization-server.example.com 21 | Content-Type: application/x-www-form-urlencoded 22 | 23 | token=random-token-value 24 | &token_type_hint=access_token 25 | ``` 26 | 27 | The `token_type_hint` parameter is optional and should be set to the type of token being introspected. If the access token is valid, the authorization server responds with the token's metadata: 28 | 29 | ```http 30 | HTTP/1.1 200 OK 31 | Content-Type: application/json 32 | 33 | { 34 | "active": true, 35 | "scope": "read write", 36 | "client_id": "client-id", 37 | "username": "johndoe", 38 | "token_type": "Bearer", 39 | "exp": 1634020800, 40 | "iat": 1634017200 41 | } 42 | ``` 43 | 44 | It's worth noting that not all authorization servers support token introspection and not all tokens are introspectable. The may limit the use of token introspection based various factors, for example, some authorization servers may not support introspection for JWTs. 45 | 46 | ### Key parameters in a token introspection request 47 | 48 | Here are two key parameters in a token introspection request: 49 | 50 | - **`token`**: The token to introspect. 51 | - **`token_type_hint`**: The type of token being introspected. It can be `access_token` or `refresh_token`. 52 | 53 | 54 | 55 | 61 | -------------------------------------------------------------------------------- /src/content/terms/en/totp.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Time-based one-time password (TOTP) 3 | tags: [authentication] 4 | description: A time-based one-time password (TOTP) is a temporary, unique code generated by an algorithm that uses the current time as a key factor. 5 | --- 6 | 7 | ## What is TOTP? 8 | 9 | A Time-Based One-Time Password (TOTP) is a temporary, unique code generated by an algorithm that uses the current time as a key factor. Similar to a generic , a TOTP is used only once, but it has a fixed lifespan, typically ranging from 30 to 60 seconds. Upon expiration, a new code is generated automatically. 10 | 11 | The TOTP standard is defined by the Internet Engineering Task Force (IETF) under [RFC 6238](https://datatracker.ietf.org/doc/html/rfc6238), and it is widely adopted in various two-factor authentication (2FA) and multi-factor authentication (MFA) systems. Because TOTPs rely on synchronized time between the client (user device) and the server, they offer a high level of security and are difficult to predict or reuse. 12 | 13 | ## How TOTP works 14 | 15 | The generation of a TOTP involves the following steps: 16 | 17 | 1. Shared secret: During the initial setup, a shared secret key is generated and stored securely on both the client and server. This key is typically encoded as a QR code which users scan using an authentication app. 18 | 2. Time intervals: The current time is divided into fixed intervals, usually of 30 seconds. 19 | 3. Algorithm application: The shared secret key and the current timestamp are fed into a hash-based algorithm (often HMAC-SHA1) to produce a unique numeric code. 20 | 4. Synchronization: Both the client and server generate the code independently using the same shared secret and current timestamp. The codes match only if both are in sync. 21 | 5. Verification: When the user logs in or performs a critical transaction, they enter the TOTP displayed on their authentication app. The server then compares it with its internally generated TOTP for validation. 22 | 23 | ## When to use TOTP 24 | 25 | In most cases, a normal OTP is recommended, but in the cases where it is unable to "trigger" a new passcode, then TOTP is recommended. 26 | 27 | - TOTP example: Authenticator App 28 | - OTP example: Email, SMS 29 | 30 | ## What are the difference between OTP and TOTP? 31 | 32 | The main difference is that TOTP is time-based, so it is suitable when the device is not connected to the server. The server can easily send a new passcode to an email address or a phone number, but that requires the email or phone to be online. However, the Authenticator App can stay offline and use "time" to verify the passcode. 33 | 34 | 35 | -------------------------------------------------------------------------------- /src/content/terms/es/auth.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Auth (desambiguación) 3 | tags: [authentication, authorization] 4 | description: El término "auth" a menudo se utiliza como abreviatura de authentication (autenticación) o authorization (autorización). Estos conceptos están relacionados pero son fundamentalmente diferentes. 5 | --- 6 | 7 | ## Auth 8 | 9 | Esta página es una desambiguación para el término "auth". A menudo se utiliza como una abreviatura para: 10 | 11 | - : El proceso de verificar la propiedad de la identidad (por ejemplo, usuario o servicio). Responde a la pregunta "¿Qué identidad posees?" 12 | - : El proceso de determinar qué acciones puede realizar una identidad sobre un recurso. Responde a la pregunta "¿Qué puedes hacer?" 13 | 14 | > [!Note] 15 | > A veces, authentication (autenticación) y authorization (autorización) se refieren como "AuthN" y "AuthZ", respectivamente. 16 | 17 | Estos dos conceptos son esenciales en el ámbito de , pero son fundamentalmente diferentes. Veamos un ejemplo: Una aplicación web MyStorage tiene la capacidad de subir archivos y conectarse a Google Drive. Un flujo de usuario típico sería: 18 | 19 | ```mermaid 20 | sequenceDiagram 21 | participant Usuario 22 | participant MyStorage 23 | participant Google 24 | autonumber 25 | 26 | Usuario->>MyStorage: Iniciar sesión en MyStorage 27 | MyStorage->>Usuario: ¡Bienvenido, Usuario! 28 | Usuario->>MyStorage: Clic en "Conectar Google Drive" 29 | MyStorage->>Google: Redirigir a Google
con solicitud de autorización 30 | Google->>Usuario: Solicitar al usuario iniciar sesión 31 | Usuario->>Google: Iniciar sesión en Google 32 | Google->>Usuario: Pedir permiso para acceder a Google Drive 33 | Usuario->>Google: Otorgar acceso a MyStorage 34 | Google->>MyStorage: Redirigir a MyStorage
con datos de autorización (por ejemplo, access token) 35 | MyStorage->>Google: Acceder al Google Drive del usuario usando el access token 36 | ``` 37 | 38 | En este flujo, el usuario realiza dos pasos de authentication (autenticación): uno con MyStorage (paso 1) y otro con Google (paso 6); y un paso de authorization (autorización): otorgar acceso a Google Drive (paso 8). 39 | 40 | ## ¿A cuál te refieres? 41 | 42 | Cuando ves el término "auth", es importante aclarar si se refiere a authentication (autenticación) o authorization (autorización); de lo contrario, podrías esperar que ambos procesos estén cubiertos (tal como lo hace este sitio web). 43 | 44 | -------------------------------------------------------------------------------- /src/content/terms/es/role.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Rol 3 | tags: [authorization] 4 | description: Un rol es un concepto central en los sistemas de control de acceso basado en roles (RBAC), que representa una colección de permisos que define qué acciones pueden realizar los usuarios, proporcionando una manera eficiente de gestionar y asignar derechos de acceso a los usuarios. 5 | --- 6 | 7 | ## Rol 8 | 9 | Un rol es uno de los componentes centrales en . Sirve como un contenedor para permisos que pueden ser asignados a usuarios, actuando como un intermediario entre los usuarios y sus derechos de acceso. 10 | 11 | ```mermaid 12 | graph LR 13 | Usuarios 14 | -->|asignado a| Roles 15 | -->|incluyendo| Permisos 16 | ``` 17 | 18 | Una estructura típica de rol contiene un nombre y un conjunto de permisos: 19 | 20 | ```typescript 21 | const role = { 22 | name: 'order_admin', 23 | permissions: [ 24 | 'read:orders', // Ver detalles de pedidos 25 | 'write:orders', // Editar pedidos 26 | 'read:products' // Ver productos 27 | ] 28 | } 29 | ``` 30 | 31 | > [!Note] 32 | > Los roles se utilizan principalmente para la gestión de permisos. Para la implementación de control de acceso (access control), se recomienda verificar los permisos directamente en lugar de los roles. Consulta para más información. 33 | 34 | -------------------------------------------------------------------------------- /src/content/terms/fr/auth.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Auth (clarification) 3 | tags: [authentication, authorization] 4 | description: Le terme "auth" est souvent utilisé comme une abréviation pour authentification ou autorisation. Ces concepts sont liés mais fondamentalement différents. 5 | --- 6 | 7 | ## Auth 8 | 9 | Cette page est une clarification pour le terme "auth". Il est souvent utilisé comme une abréviation pour : 10 | 11 | - : Le processus de vérification de la propriété d'identité (par exemple, utilisateur ou service). Il répond à la question "Quelle identité possédez-vous ?" 12 | - : Le processus de détermination des actions qu'une identité peut effectuer sur une ressource. Il répond à la question "Que pouvez-vous faire ?" 13 | 14 | > [!Note] 15 | > Parfois, authentification et autorisation sont appelées respectivement "AuthN" et "AuthZ". 16 | 17 | Ces deux concepts sont tous deux essentiels dans le domaine de l' , mais ils sont fondamentalement différents. Voyons un exemple : une application web MyStorage a la capacité de télécharger des fichiers et de se connecter à Google Drive. Un flux utilisateur typique serait : 18 | 19 | ```mermaid 20 | sequenceDiagram 21 | participant Utilisateur 22 | participant MyStorage 23 | participant Google 24 | autonumber 25 | 26 | Utilisateur->>MyStorage: Se connecter à MyStorage 27 | MyStorage->>Utilisateur: Bienvenue, Utilisateur ! 28 | Utilisateur->>MyStorage: Cliquer sur "Connecter Google Drive" 29 | MyStorage->>Google: Rediriger vers Google
avec une demande d'authorization (authorization request) 30 | Google->>Utilisateur: Demander à l'utilisateur de se connecter 31 | Utilisateur->>Google: Se connecter à Google 32 | Google->>Utilisateur: Demander la permission pour accéder à Google Drive 33 | Utilisateur->>Google: Accorder l'accès à MyStorage 34 | Google->>MyStorage: Rediriger vers MyStorage
avec des données d'authorization (par exemple, access token) 35 | MyStorage->>Google: Accéder à Google Drive de l'utilisateur en utilisant l' access token 36 | ``` 37 | 38 | Dans ce flux, l'utilisateur effectue deux étapes d'authentification : une avec MyStorage (étape 1) et une autre avec Google (étape 6) ; et une étape d'autorisation : accorder l'accès à Google Drive (étape 8). 39 | 40 | ## De quoi voulez-vous parler ? 41 | 42 | Lorsque vous voyez le terme "auth", il est important de préciser s'il se réfère à l'authentification ou à l'autorisation ; sinon, vous pourriez vous attendre à ce que les deux processus soient couverts (tout comme ce site le fait). 43 | 44 | -------------------------------------------------------------------------------- /src/content/terms/fr/role.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Rôle 3 | tags: [authorization] 4 | description: Un rôle est un concept central dans les systèmes de contrôle d'accès basé sur les rôles (RBAC), représentant un ensemble d'autorisations qui définit quelles actions les utilisateurs peuvent effectuer, offrant un moyen efficace de gérer et d'attribuer des droits d'accès aux utilisateurs. 5 | --- 6 | 7 | ## Rôle 8 | 9 | Un rôle est l'un des composants centraux dans . Il sert de conteneur pour les autorisations qui peuvent être attribuées aux utilisateurs, agissant comme un intermédiaire entre les utilisateurs et leurs droits d'accès. 10 | 11 | ```mermaid 12 | graph LR 13 | Utilisateurs 14 | -->|attribué à| Rôles 15 | -->|incluant| Permissions 16 | ``` 17 | 18 | Une structure de rôle typique contient un nom et un ensemble d'autorisations : 19 | 20 | ```typescript 21 | const role = { 22 | name: 'order_admin', 23 | permissions: [ 24 | 'read:orders', // Voir les détails des commandes 25 | 'write:orders', // Modifier les commandes 26 | 'read:products' // Voir les produits 27 | ] 28 | } 29 | ``` 30 | 31 | > [!Note] 32 | > Les rôles sont principalement utilisés pour la gestion des autorisations. Pour la mise en œuvre du contrôle d'accès, il est recommandé de vérifier directement les autorisations plutôt que les rôles. Voir pour plus d'informations. 33 | 34 | -------------------------------------------------------------------------------- /src/content/terms/it/auth.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Auth (disambiguazione) 3 | tags: [authentication, authorization] 4 | description: Il termine "auth" è spesso usato come abbreviazione per authentication (autenticazione) o authorization (autorizzazione). Questi concetti sono correlati ma fondamentalmente diversi. 5 | --- 6 | 7 | ## Auth 8 | 9 | Questa pagina è una disambiguazione per il termine "auth". È spesso usato come abbreviazione per: 10 | 11 | - : Il processo di verifica della proprietà dell'identità (ad esempio, utente o servizio). Risponde alla domanda "Quale identità possiedi?" 12 | - : Il processo di determinazione delle azioni che un'identità può eseguire su una risorsa. Risponde alla domanda "Cosa puoi fare?" 13 | 14 | > [!Note] 15 | > A volte, authentication (autenticazione) e authorization (autorizzazione) sono indicate rispettivamente come "AuthN" e "AuthZ". 16 | 17 | Questi due concetti sono entrambi essenziali nel regno di , ma sono fondamentalmente diversi. Vediamo un esempio: un'applicazione web MyStorage ha la capacità di caricare file e connettersi a Google Drive. Un tipico flusso utente sarebbe: 18 | 19 | ```mermaid 20 | sequenceDiagram 21 | participant User 22 | participant MyStorage 23 | participant Google 24 | autonumber 25 | 26 | User->>MyStorage: Accedi a MyStorage 27 | MyStorage->>User: Benvenuto, Utente! 28 | User->>MyStorage: Clicca "Connetti Google Drive" 29 | MyStorage->>Google: Reindirizza a Google
con authorization request 30 | Google->>User: Chiedi all'utente di accedere 31 | User->>Google: Accedi a Google 32 | Google->>User: Chiedi il permesso di accedere a Google Drive 33 | User->>Google: Concedi l'accesso a MyStorage 34 | Google->>MyStorage: Reindirizza a MyStorage
con dati di autorizzazione (ad esempio, access token) 35 | MyStorage->>Google: Accedi a Google Drive dell'utente utilizzando l'access token 36 | ``` 37 | 38 | In questo flusso, l'utente esegue due passaggi di authentication (autenticazione): uno con MyStorage (passaggio 1) e un altro con Google (passaggio 6); e un passaggio di authorization (autorizzazione): concedere l'accesso a Google Drive (passaggio 8). 39 | 40 | ## A quale ti riferisci? 41 | 42 | Quando vedi il termine "auth", è importante chiarire se si riferisce a authentication (autenticazione) o authorization (autorizzazione); altrimenti, potresti aspettarti che entrambi i processi siano coperti (proprio come fa questo sito web). 43 | 44 | -------------------------------------------------------------------------------- /src/content/terms/it/role.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Ruolo 3 | tags: [authorization] 4 | description: Un ruolo è un concetto fondamentale nei sistemi di controllo degli accessi basato sui ruoli (RBAC), rappresentando una raccolta di permessi che definisce quali azioni gli utenti possono eseguire, fornendo un modo efficiente per gestire e assegnare i diritti di accesso agli utenti. 5 | --- 6 | 7 | ## Ruolo 8 | 9 | Un ruolo è uno dei componenti fondamentali in . Serve come contenitore per i permessi che possono essere assegnati agli utenti, agendo come intermediario tra gli utenti e i loro diritti di accesso. 10 | 11 | ```mermaid 12 | graph LR 13 | Users 14 | -->|assegnato a| Roles 15 | -->|inclusi| Permissions 16 | ``` 17 | 18 | Una struttura tipica di un ruolo contiene un nome e un insieme di permessi: 19 | 20 | ```typescript 21 | const role = { 22 | name: 'order_admin', 23 | permissions: [ 24 | 'read:orders', // Visualizzare i dettagli degli ordini 25 | 'write:orders', // Modificare gli ordini 26 | 'read:products' // Visualizzare i prodotti 27 | ] 28 | } 29 | ``` 30 | 31 | > [!Note] 32 | > I ruoli sono utilizzati principalmente per la gestione dei permessi. Per l'implementazione del controllo degli accessi, è consigliato controllare direttamente i permessi piuttosto che i ruoli. Vedi per maggiori informazioni. 33 | 34 | -------------------------------------------------------------------------------- /src/content/terms/ja/auth.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 認証 (Auth, disambiguation) 3 | tags: [authentication, authorization] 4 | description: 「auth」という用語は、認証 (authentication) または認可 (authorization) の略としてよく使用されます。これらの概念は関連していますが、根本的に異なります。 5 | --- 6 | 7 | ## 認証 (Auth) 8 | 9 | このページは、「auth」という用語の曖昧さを解消するためのものです。この用語は以下のような略語としてよく使用されます： 10 | 11 | - : アイデンティティの所有を確認するプロセス（例：ユーザーやサービス）。「どのアイデンティティを所有していますか？」という質問に答えます。 12 | - : アイデンティティがリソース上でどのアクションを実行できるかを決定するプロセス。「何ができますか？」という質問に答えます。 13 | 14 | > [!Note] 15 | > 時には、認証 (authentication) と認可 (authorization) はそれぞれ「AuthN」および「AuthZ」として言及されることがあります。 16 | 17 | これら二つの概念は、 領域においてどちらも重要ですが、根本的に異なります。例を見てみましょう：ウェブアプリケーションの MyStorage には、ファイルをアップロードして Google ドライブに接続する機能があります。典型的なユーザーフローは次のようになります： 18 | 19 | ```mermaid 20 | sequenceDiagram 21 | participant User 22 | participant MyStorage 23 | participant Google 24 | autonumber 25 | 26 | User->>MyStorage: MyStorage にサインイン 27 | MyStorage->>User: ようこそ、User さん！ 28 | User->>MyStorage: 「Google ドライブに接続」をクリック 29 | MyStorage->>Google: 認可リクエストとともに Google にリダイレクト 30 | Google->>User: ユーザーにサインインを促す 31 | User->>Google: Google にサインイン 32 | Google->>User: Google ドライブへのアクセス許可を求める 33 | User->>Google: MyStorage へのアクセスを許可 34 | Google->>MyStorage: 認可データ（例：アクセストークン）とともに MyStorage にリダイレクト 35 | MyStorage->>Google: アクセストークンを用いてユーザーの Google ドライブにアクセス 36 | ``` 37 | 38 | このフローでは、ユーザーは二度の認証 (authentication) ステップを行います：MyStorage での認証 (ステップ 1) と、Google での認証 (ステップ 6) です。また、Google ドライブへのアクセスを許可する一度の認可 (authorization) ステップがあります (ステップ8)。 39 | 40 | ## どれを意味していますか？ 41 | 42 | 「auth」という用語を目にしたとき、それが認証 (authentication) を指しているのか認可 (authorization) を指しているのかを明確にすることが重要です。そうしないと、両方のプロセスがカバーされていると期待してしまうかもしれません（このウェブサイトがそうしているように）。 43 | 44 | 45 | -------------------------------------------------------------------------------- /src/content/terms/ja/authorization.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 認可 (Authorization) 3 | tags: [authorization] 4 | description: 認可 (Authorization) は、あるアイデンティティがリソース上でどのようなアクションを実行できるかを決定するプロセスです。アクセス ポリシーを定義し、適用するための基本的なセキュリティ メカニズムです。 5 | --- 6 | 7 | ## 認可 (Authorization) とは何ですか？ 8 | 9 | > **要約**: 認可 (Authorization) とは「何ができるのか？」という質問に答えるものです。 10 | 11 | 認可 (Authorization) とは、アイデンティティ（ユーザー、サービス、デバイス）が特定のリソースに対して特定のアクションを実行するための必要な権限を持っているかを判断する意思決定プロセスです。いくつかの例を見てみましょう: 12 | 13 | - オンラインドキュメントエディタでは、ユーザーがドキュメントを他の人と共有できます。 14 | - クラウドストレージサービスでは、サービスが特定のフォルダ内のファイルを読み書きできます。 15 | - スマートホームシステムでは、デバイスがリビングルームの電気を点灯させることができます。 16 | 17 | これらすべての例には、アイデンティティ（主体）がリソースに対してアクションを実行することが含まれます。当然ながら、認可 (Authorization) が失敗することもあります。たとえば、ユーザーがアクセスする権限のないファイルを削除しようとした場合などです。 18 | 19 | 認可 (Authorization) の基本モデルは簡単です: **アイデンティティ** が **リソース** に対して **アクション** を実行したときに、**許可する** または **拒否する** というものです。 20 | 21 | ### 認証 (Authentication) と認可 (Authorization) の違い 22 | 23 | 認証 (Authentication) と認可 (Authorization) はよく混同されますが、本質的に異なります。 が「どのアイデンティティを所有していますか？」という質問に答えるのに対し、認可 (Authorization) はアクセス決定を行う前に、システムがアイデンティティを知る必要があるため、多くの場合、認証後に認可 (Authorization) が行われます。 24 | 25 | ### 認可 (Authorization) とアクセス制御 (Access Control) の違い 26 | 27 | 認可 (Authorization) はアクセス制御 (Access Control) の一部です。アクセス制御はより広い概念であり、認可 (Authorization) やその他のアクセス管理制限が含まれます。言い換えれば、アクセス制御はリソースへのアクセスを選択的に制限する一般的な用語であり、認可 (Authorization) は特に意思決定プロセスについてです。 28 | 29 | ## 認可 (Authorization) はどのように機能しますか？ 30 | 31 | 認可 (Authorization) は通常、 を使用して実装されます。これらは、システム内での権限の割り当てと適用方法を定義します。 32 | 33 | ## 認可 (Authorization) フレームワーク（プロトコル） 34 | 35 | は非常に人気のある認可 (Authorization) フレームワークですが、OAuth 2.0 はどのアクセス制御モデルを使用するかを定義しているわけではないことに注意が必要です。代わりに、認可 (Authorization) の委任とアクセストークンの発行に焦点を当てています。 36 | 37 | つまり、OAuth 2.0 は、ユーザーがクライアントに自分のリソースへのアクセス許可を与えるサードパーティーの認可 (Authorization) シナリオに適しています。たとえば、Google アカウントを使用してウェブサイトにサインインする場合、ユーザーはそのウェブサイトが自分の Google プロフィールにアクセスすることを認可 (Authorization) しています。 38 | 39 | もしファーストパーティーの認可 (Authorization) に取り組んでいる（例: 自分のアプリケーションや組織内で）場合は、 や などのアクセス制御モデルを実装する必要があるかもしれません。 とアクセス制御モデルの組み合わせにより、認証と認可 (Authorization) のための堅実な基盤を提供できます。 40 | 41 | 独自の認可 (Authorization) システムを構築するのではなく、認証と認可 (Authorization) 機能を提供する を使用することをお勧めします。良いアイデンティティプロバイダーは、アクセス制御の複雑さを処理し、アプリケーションに対して安全でスケーラブルなソリューションを提供します。 42 | 43 | 44 | 45 | -------------------------------------------------------------------------------- /src/content/terms/ja/jwe.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: JSON Web Encryption (JWE) 3 | tags: [oidc, jose] 4 | description: JSON Web Encryption (JWE) は JSON 形式のデータを暗号化および復号化する標準的な方法です。これは、JSON Web Tokens (JWTs) 内の機密情報を保護するためによく使用されます。 5 | --- 6 | 7 | ## JSON Web Encryption (JWE) とは？ 8 | 9 | RFC 7516 で定義されているように、JSON Web Encryption (JWE) は JSON 形式のデータを暗号化および復号化するためのメカニズムです。データに機密性の層を追加し、信頼できないネットワーク上で機密情報を送信する際に特に有用です。 10 | 11 | JWE はしばしば JSON Web Tokens (JWTs) と組み合わせて、ペイロードデータを保護するために使用されます。たとえば、 や は JWE を使用して暗号化され、データが送信中にセキュリティが確保されるようにすることができます。 12 | 13 | ## JWE の仕組み 14 | 15 | JWE にはコンパクト形式と JSON 形式の 2 つのシリアライゼーションがあります。各形式には暗号化データを表す独自の方法があります。 16 | 17 | ### コンパクトシリアライゼーション 18 | 19 | コンパクトシリアライゼーションでは、JWE はドット (`.`) で区切られた 5 つの Base64URL エンコードされた部分として表されます。5 つの部分は次の通りです： 20 | 21 | ``` 22 | {{header}}.{{encrypted-key}}.{{iv}}.{{ciphertext}}.{{tag}} 23 | ``` 24 | 25 | 各部分の目的は次の通りです： 26 | 27 | - `header`: 暗号化アルゴリズムとキー管理に関するメタデータを含む。 28 | - `encrypted-key`: ペイロードを暗号化するために使用される暗号化されたコンテンツ暗号鍵 (CEK)。 29 | - `iv`: 暗号化プロセスで使用される初期化ベクトル。 30 | - `ciphertext`: 暗号化されたペイロードデータ。 31 | - `tag`: 暗号化データの整合性を確認するために使用される認証タグ。 32 | 33 | ### JSON シリアライゼーション 34 | 35 | JSON シリアライゼーションはより冗長で、JWE を表現する構造化された方法を提供します。JWE は次のプロパティを持つ JSON オブジェクトとして表されます： 36 | 37 | ```json 38 | { 39 | "protected": "{{protected-header}}", 40 | "unprotected": "{{unprotected-header}}", 41 | "header": "{{header}}", 42 | "encrypted_key": "{{encrypted-key}}", 43 | "iv": "{{iv}}", 44 | "ciphertext": "{{ciphertext}}", 45 | "tag": "{{tag}}", 46 | "aad": "{{additional-authenticated-data}}" 47 | } 48 | ``` 49 | 50 | - `protected`: Base64URL エンコードされた保護ヘッダーを含む。 51 | - `unprotected`: JWE の共有される保護なしヘッダーを含む。 52 | - `header`: JWE の各受信者用の保護されないヘッダーを含む。 53 | - `encrypted_key`: Base64URL エンコードされた暗号化されたコンテンツ暗号鍵 (CEK) を含む。 54 | - `iv`: Base64URL エンコードされた初期化ベクトルを含む。 55 | - `ciphertext`: Base64URL エンコードされた暗号文 (暗号化されたペイロード) を含む。 56 | - `tag`: Base64URL エンコードされた認証タグを含む。 57 | - `aad`: Base64URL エンコードされた追加認証データを含む。 58 | 59 | --- 60 | 61 | クライアントは適切なキーとアルゴリズムを使用して JWE を復号化できる必要があります。事前にコミュニケーションされたキーやキー合意プロトコルから導出されたキーを用いて JWE を復号化することができます。 62 | 63 | たとえば、 が JWE を使用して暗号化され、クライアントは OpenID プロバイダーの `jwks_uri` エンドポイントから得られた適切なキーを使用してこれを復号化できます。 64 | 65 | 66 | 67 | -------------------------------------------------------------------------------- /src/content/terms/ja/otp.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: ワンタイムパスワード (One-time password, OTP) 3 | tags: [authentication] 4 | description: ワンタイムパスワード (OTP) は、単一の取引またはサインインセッションに使用される一意で一時的なコードです。 5 | --- 6 | 7 | ## OTP とは何ですか？ 8 | 9 | ワンタイムパスワード (OTP) は、単一の取引またはサインインセッションに使用される一意で一時的なコードです。従来のパスワードは静的で、ユーザーが変更するまで同じですが、OTP は動的で発行後すぐに期限切れになることが多く、通常は数分以内です。この動的な性質により、OTP は非常に安全性が高まり、悪意のある第三者によってOTPが傍受されたとしても、不正アクセスのリスクが大幅に減少します。 10 | 11 | OTP は通常、時間同期や数学的計算に基づくアルゴリズムを使用して生成され、各コードが一意で予測不可能であることを保証します。ユーザーは通常、SMS、メール、モバイルアプリ、またはハードウェアトークンを通じて OTP を受け取ります。 12 | 13 | ## OTP (ワンタイムパスワード) の一般的な使用例は何ですか？ 14 | 15 | OTP の主な使用例は以下の通りです： 16 | 17 | ### パスワードレスサインイン 18 | 19 | 多くのウェブサイトやアプリケーションが、セキュリティを高め、ユーザーの利便性を向上させるためにパスワードレスサインインオプションを提供しています。ユーザーは、登録された携帯番号やメールに送信された OTP をリクエストして、自分の身元を認証することができ、複雑なパスワードを覚える必要がありません。この方法は、サインインプロセスを簡素化するだけでなく、パスワード関連の侵害リスクも低減します。 20 | 21 | ### パスワードの回復 22 | 23 | ユーザーがパスワードを忘れた場合、OTP はアカウント回復のための安全な方法として役立ちます。ユーザーは OTP をリクエストし、登録されたメールや電話番号に送信されたOTP を使って身元を確認し、パスワードをリセットすることができます。このプロセスは、正当なアカウント所有者のみが回復を行えることを保証します。 24 | 25 | ### 多要素認証 (MFA) 26 | 27 | OTP は多要素認証 (MFA) の重要な要素であり、ユーザーが知っているもの（パスワードのようなもの）とユーザーが持っているもの（モバイルデバイスのようなもの）を組み合わせます。ユーザーは、メインパスワードを入力した後に OTP を受け取り、それを入力することでアクセスを得ることができます。この追加のセキュリティレイヤーにより、メインパスワードが侵害されたとしても、不正アクセスの可能性が大幅に減少します。 28 | 29 | ### 機密性の高い取引の確認 30 | 31 | オンラインバンキングや高額購入など、機密データや重要な取引が関与する活動では、OTPはユーザーの同意を確認するためのセキュリティ手段として機能します。これらのアクションを完了する前に、ユーザーに登録された連絡方法に OTP が送信され、トランザクションを完了するために入力する必要があります。これにより、たとえ誰かがユーザーのアカウントにアクセスできたとしても、OTP がなければ重要なアクションを実行できません。 32 | 33 | 34 | -------------------------------------------------------------------------------- /src/content/terms/ja/resource-owner.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: リソース所有者 (Resource owner) 3 | tags: [oauth 2.0] 4 | description: リソース所有者は、保護されたリソースへのアクセスを許可する能力を持つアイデンティティ（通常はユーザー）です。OAuth 2.0 では、リソース所有者はリソースサーバーにおいて、クライアントが代理でそのリソースにアクセスすることを許可できます。 5 | --- 6 | 7 | ## リソース所有者とは何か？ 8 | 9 | のコンテキストでは、リソース所有者とは、保護されたリソース（例えばデータ、ファイル、サービスなど）へのアクセスを許可する能力を持つアイデンティティ（通常はユーザー）です。 10 | 11 | 例えば、ユーザーの Google Drive にアクセスしたい Web アプリケーション MyApp があるとします。以下は典型的な OAuth 2.0 のフローです： 12 | 13 | ```mermaid 14 | sequenceDiagram 15 | participant User 16 | participant MyApp 17 | participant Google 18 | 19 | User->>MyApp: MyApp を開いて
「Google Drive と接続」をクリック 20 | MyApp->>Google: 認可リクエストで
Google にリダイレクト 21 | Google->>User: Google にサインイン 22 | User->>Google: サインイン 23 | Google->>User: Google Drive へのアクセス権限を
求める 24 | User->>Google: MyApp にアクセスを許可 25 | Google->>MyApp: 認可データ（例：アクストークン）を
MyApp にリダイレクト 26 | MyApp->>Google: アクセストークンを使って
ユーザーの Google Drive にアクセス 27 | ``` 28 | 29 | このフローでは、**ユーザー**が**リソース所有者**であり、自分の Google Drive へのアクセス権を MyApp に許可します。一方、**MyApp** は保護されたリソースにアクセスしたい であり、**Google** は であり、同時に でもあります。 30 | 31 | 名前が示すように、リソース所有者は においていくつかのリソースを所有し、 コンテキストでクライアントが代理でそれらにアクセスすることを許可できます。 32 | 33 | ## リソース所有者はなぜ重要か？ 34 | 35 | プロセスにおいて、リソース所有者は、自分のリソースへのアクセスを明示的に許可または拒否する唯一の人物であるため、欠かせない存在です。リソース所有者の同意は、技術的およびコンプライアンスの両方の理由で必須です： 36 | 37 | - **技術的**：リソース所有者の同意により、クライアントがリソースにアクセスするために必要な権限を持つことが保証されます。すべてまたは何もないアクセスではなく、リソース所有者はクライアントのリクエストに従って部分的なアクセスを許可することがあります。一方で、リソース所有者はいつでもアクセスを明示的に取り消すこともできます。この方法により、 のための明確で監査可能な手段が提供されます。 38 | - **コンプライアンス**：リソース所有者の同意は、特に機密データを扱う場合、多くの法管轄地で法的要件です。例えば、一般データ保護規則（GDPR）は、データ主体（リソース所有者）がデータ処理活動に対して明示的な同意を提供することを義務付けています。 39 | 40 | ## リソース所有者 vs. リソースサーバー 41 | 42 | リソースサーバーは、**保護されたリソース**をホスティングおよび提供する責任を負います。彼らはアクセストークンを確認し、クライアントにリソースを提供する関門になります。 43 | 44 | 一方、リソース所有者は、 ポリシーに従って、リソースサーバー内の保護されたリソースに対して完全または部分的なコントロールを持つことがあります。 45 | 46 | 47 | 48 | 53 | -------------------------------------------------------------------------------- /src/content/terms/ja/role.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: ロール (Role) 3 | tags: [authorization] 4 | description: ロールは、ロールベースのアクセス制御 (RBAC) システムにおけるコア概念であり、ユーザーが実行できるアクションを定義する権限の集合を表し、ユーザーへのアクセス権を効率的に管理および割り当てる方法を提供します。 5 | --- 6 | 7 | ## ロール (Role) 8 | 9 | ロール (Role) は、 のコアコンポーネントの一つです。これは、ユーザーに割り当てることができる権限のコンテナとして機能し、ユーザーとそのアクセス権の間の仲介役を果たします。 10 | 11 | ```mermaid 12 | graph LR 13 | Users 14 | -->|assigned to| Roles 15 | -->|including| Permissions 16 | ``` 17 | 18 | 典型的なロールの構造は、名前と一連の権限を含みます: 19 | 20 | ```typescript 21 | const role = { 22 | name: 'order_admin', 23 | permissions: [ 24 | 'read:orders', // 注文詳細の表示 25 | 'write:orders', // 注文の編集 26 | 'read:products' // 製品の表示 27 | ] 28 | } 29 | ``` 30 | 31 | > [!Note] 32 | > ロールは主に権限管理に使用されます。アクセス制御の実装には、ロールではなく権限を直接確認することをお勧めします。詳細は を参照してください。 33 | 34 | -------------------------------------------------------------------------------- /src/content/terms/ja/scope.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: スコープ (Scope) 3 | tags: [authorization] 4 | description: スコープ (Scope) は、アプリケーションがユーザーの保護されたリソースにアクセスするために要求する権限を定義します。これは、OAuth 2.0 および OIDC における基本的な概念であり、アプリケーションがユーザーのデータにどの程度アクセスできるかを制御します。 5 | --- 6 | 7 | ## スコープ (Scope) とは何か？ 8 | 9 | と プロトコルにおいて、**スコープ (Scope)** は、アプリケーションがユーザーのリソースに対して持つアクセスを制限するためのメカニズムです。これは、アプリケーションがユーザーから要求する権限を定義します。 10 | 11 | スコープは、認可サーバーによって定義される文字列として表されます。アプリケーションがユーザーのリソースへのアクセスを要求するとき、認可リクエストに必要なスコープを指定します。ユーザーは認可プロセス中にこれらの権限を許可または拒否するよう促されます。 12 | 13 | ### なぜスコープ (Scope) を使用するのか？ 14 | 15 | - **細かいアクセス制御**: スコープにより、アプリケーションは特定のアクションを実行するために必要な権限のみを要求でき、不正なアクセスのリスクを減少させます。 16 | - **ユーザー同意**: スコープは、アプリケーションがどのようなデータにアクセスし、なぜそれが必要かをユーザーに理解させます。 17 | - **セキュリティ**: スコープは、アプリケーションがアクセス権を超えないようにし、ユーザーのデータのセキュリティを向上させます。 18 | 19 | ## スコープ (Scope) はどのように機能するか？ 20 | 21 | アプリケーションが OAuth 2.0 / OIDC 認可プロセスを開始するとき、認可リクエストにスコープのリストを含めます。その後、認可サーバーはユーザーに要求されたスコープを一覧表示した同意画面を提示します。ユーザーは各スコープへのアクセスを許可または拒否することを選択できます。このプロセスは、通常、ユーザーのリソースへのアクセスが必要なサードパーティアプリケーションの場合に使用されます。 22 | 23 | 別の方法として、アプリケーションが認可サーバーから信頼されている場合、ユーザーが同意を求められないこともあり、自動同意が行われ、要求されたすべてのスコープが許可されます。 24 | 25 | ## スコープ (Scope) の定義 26 | 27 | スコープは通常、API プロバイダーによって定義されます。それらは次のようになります: 28 | - **標準スコープ**: OAuth 2.0 仕様によって定義された、さまざまなアプリケーションやサービスで共有される一般的に使用されるスコープ。例: `openid`, `profile`, `email`。 29 | - **カスタムスコープ**: アプリケーションまたはサービスに固有で、その独自の要件に合わせたもの。例: `read:orders`, `write:comments`。 30 | 31 | ## OIDC とアイデンティティ管理においてスコープ (Scope) はどこで使用されるか？ 32 | 33 | スコープは、OIDC のさまざまな側面で使用されますが、次に限定されません: 34 | 35 | - **認証 (Authentication)**: スコープは、認証プロセス中に特定のユーザー情報を要求するために使用できます。例: `profile`, `email`。 36 | - **認可 (Authorization)**: スコープは、特定のリソースへのアクセスや特定のアクションを実行するために使用できます。例: `read:orders`, `write:comments`。 37 | - **同意**: スコープは、アプリケーションが要求する権限をユーザーに知らせるために同意画面に表示されます。 38 | - **トークン発行**: スコープは、アプリケーションに許可された権限を示すためにトークン応答に含まれます。 39 | - **トークンの検証**: スコープは、アプリケーションが保護されたリソースにアクセスするためにトークンを提示した際に、そのアクセス権を検証するために使用できます。 40 | - **リソースサーバー**: スコープは、リソースサーバーがアプリケーションに許可された権限に基づいてアクセス制御ポリシーを実施するために使用されます。 41 | - **ユーザープロファイル**: スコープは、基本的なクレームを超えるユーザープロファイル情報を要求するために使用できます。 42 | 43 | ## ベストプラクティス 44 | 45 | - **最小限のスコープを要求する**: 常にアプリケーションが機能するために必要な最小限のスコープのみを要求してください。これにより、過剰な権限のリスクが最小化され、ユーザーの信頼が向上します。 46 | - **スコープの使用を説明する**: 各スコープが必要な理由をユーザーに明確に説明してください。透明性はユーザーの同意を得る助けとなります。 47 | - **可能な場合は標準スコープを使用する**: 標準スコープを利用して、互換性を確保し、複雑さを減少させます。 48 | 49 | 50 | 51 | -------------------------------------------------------------------------------- /src/content/terms/ja/service-provider.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: サービスプロバイダー (Service provider, SP) 3 | tags: [authentication, authorization] 4 | description: サービスプロバイダー (SP) は、認証 (Authentication) および認可のためにアイデンティティプロバイダー (IdP) に依存するアプリケーションまたはサービスです。 5 | --- 6 | 7 | ## サービスプロバイダー (SP) とは？ 8 | 9 | の領域において、サービスプロバイダー (SP)（または の文脈における**依存パーティ**）は、認証 (Authentication) および認可のために に依存するアプリケーションまたはサービスです。サービスプロバイダーは、ユーザーにサービスを提供し、アイデンティティプロバイダーによって発行されたトークンに基づいて ポリシーを強制します。 10 | 11 | ```mermaid 12 | graph LR 13 | IdP[アイデンティティプロバイダー] 14 | SP["サービスプロバイダー
(アプリケーション、サービス、API)"] 15 | IdP -->|ユーザーを認証する| SP 16 | IdP -->|トークンを発行する| SP 17 | IdP -->|ユーザー情報を提供する| SP 18 | ``` 19 | 20 | ## サービスプロバイダーの標準 21 | 22 | サービスプロバイダーには厳格な標準はありませんが、アイデンティティ管理を必要とする任意のタイプのアプリケーションやサービスになることがあります。しかし、サービスプロバイダーは依存するアイデンティティプロバイダーによって設定された標準に従うことがよくあります。例えば、アイデンティティプロバイダーが をサポートしている場合、サービスプロバイダーは通常、認証 (Authentication) および認可に OIDC を使用します。 23 | 24 | ## サービスプロバイダーのアーキテクチャ 25 | 26 | 「サービスプロバイダー」という用語は、特定のアーキテクチャや実装を指定するものではありません。通常、サービスプロバイダーは信頼を確立し、安全な通信を可能にするためにアイデンティティプロバイダーに登録する必要があります。登録プロセスには通常、メタデータとクライアント認証情報の交換が含まれます。 27 | 28 | 例えば、OpenID Connect の文脈では、サービスプロバイダーのメタデータには通常以下が含まれます： 29 | 30 | - **クライアント ID**: サービスプロバイダーのための一意の識別子。 31 | - **クライアントシークレット**: サービスプロバイダーを認証するために使用される共通の秘密。 32 | - **リダイレクト URI**: アイデンティティプロバイダーが認証 (Authentication) および認可の後にユーザーを戻す URI。 33 | 34 | 登録が完了すると、サービスプロバイダーはユーザーをアイデンティティプロバイダーの指定したエンドポイントにリダイレクトすることにより、 プロセスを開始できます。 35 | 36 | 対話を伴わないユースケースのために構築されたサービスプロバイダーは、 通信を必要とする クライアント と呼ばれることがよくあります。 37 | 38 | 39 | 40 | 47 | -------------------------------------------------------------------------------- /src/content/terms/ja/token-introspection.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: トークンインスペクション (Token introspection) 3 | tags: [oauth 2.0, oidc] 4 | description: トークンインスペクション (Token introspection) は、クライアント (clients) が認可サーバー (authorization server) にアクセスできるトークンを照会して検証し、それに関するメタデータを取得できるようにする OAuth 2.0 の拡張機能です。 5 | --- 6 | 7 | ## トークンインスペクション (Token introspection) とは？ 8 | 9 | トークンインスペクション (Token introspection) は、[RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662) に定義されている OAuth 2.0 の拡張機能であり、クライアント (clients) が認可サーバー (authorization server)にアクセスできるトークンを照会して検証し、それに関するメタデータを取得できるようにします。この拡張は以下の場合に便利です： 10 | 11 | - クライアントがアクセスできるトークンをリアルタイムで検証したい場合。 12 | - オペークトークン (opaque token)（自己包含されていない）であり、認可サーバーに検証を求める必要がある場合。 13 | 14 | ## トークンインスペクション (Token introspection) はどのように機能しますか？ 15 | 16 | 以下は、トークンインスペクション (Token introspection) リクエストの非規範的な例です： 17 | 18 | ```http 19 | POST /introspect HTTP/1.1 20 | Host: authorization-server.example.com 21 | Content-Type: application/x-www-form-urlencoded 22 | 23 | token=random-token-value 24 | &token_type_hint=access_token 25 | ``` 26 | 27 | `token_type_hint` パラメーターはオプションで、インスペクションするトークンのタイプに設定されるべきです。アクセスできるトークンが有効であれば、認可サーバーはトークンのメタデータで応答します： 28 | 29 | ```http 30 | HTTP/1.1 200 OK 31 | Content-Type: application/json 32 | 33 | { 34 | "active": true, 35 | "scope": "read write", 36 | "client_id": "client-id", 37 | "username": "johndoe", 38 | "token_type": "Bearer", 39 | "exp": 1634020800, 40 | "iat": 1634017200 41 | } 42 | ``` 43 | 44 | すべての認可サーバーがトークンインスペクション (Token introspection) をサポートするわけではなく、すべてのトークンがインスペクションされるわけではないことを注意してください。認可サーバー (authorization server)はさまざまな要因に基づいてトークンインスペクションの使用を制限する場合があります。例えば、いくつかの認可サーバーはJWTsのインスペクションをサポートしないかもしれません。 45 | 46 | ### トークンインスペクション (Token introspection) リクエストの主要パラメーター 47 | 48 | ここに、トークンインスペクション (Token introspection) リクエストの主要な 2 つのパラメーターがあります： 49 | 50 | - **`token`**: インスペクションするトークン。 51 | - **`token_type_hint`**: インスペクションするトークンのタイプ。それは `access_token` または `refresh_token` になることができます。 52 | 53 | 54 | 55 | -------------------------------------------------------------------------------- /src/content/terms/ja/totp.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 時間ベースのワンタイムパスワード (Time-based one-time password, TOTP) 3 | tags: [authentication] 4 | description: 時間ベースのワンタイムパスワード (TOTP) は、現在の時刻を主要な要素として使用するアルゴリズムによって生成される、一時的でユニークなコードです。 5 | --- 6 | 7 | ## TOTP とは何ですか？ 8 | 9 | 時間ベースのワンタイムパスワード (Time-Based One-Time Password, TOTP) は、現在の時刻を主要な要素として使用するアルゴリズムによって生成される、一時的でユニークなコードです。一般的な と同様に、TOTP は一度しか使用されませんが、通常 30 秒から 60 秒の固定寿命があります。期限が切れると、自動的に新しいコードが生成されます。 10 | 11 | TOTP 標準はインターネット技術特別策定チーム (IETF) によって [RFC 6238](https://datatracker.ietf.org/doc/html/rfc6238) に定義されており、様々な二要素認証 (2FA) や多要素認証 (MFA) システムで広く採用されています。TOTP はクライアント (ユーザーデバイス) とサーバー間の同期された時間に依存しているため、高レベルのセキュリティを提供し、予測や再利用が困難です。 12 | 13 | ## TOTP の仕組み 14 | 15 | TOTP の生成には以下のステップが含まれます： 16 | 17 | 1. 共有秘密: 初回セットアップ時に、共有の秘密鍵が生成され、クライアントとサーバーの両方に安全に保存されます。この鍵は通常 QR コードとしてエンコードされ、ユーザーは認証アプリを使用してスキャンします。 18 | 2. 時間間隔: 現在の時刻は通常 30 秒の固定間隔で区切られます。 19 | 3. アルゴリズムの適用: 共有秘密鍵と現在のタイムスタンプがハッシュベースのアルゴリズム (多くの場合 HMAC-SHA1) に供給され、ユニークな数値コードが生成されます。 20 | 4. 同期: クライアントとサーバーの両方が同じ共有秘密と現在のタイムスタンプを使用してコードを個別に生成します。コードは両者が同期している場合のみ一致します。 21 | 5. 検証: ユーザーがログインまたは重要な取引を行う際、認証アプリに表示される TOTP を入力します。その後サーバーは内部生成した TOTP と比較し検証します。 22 | 23 | ## TOTP を使用する場合 24 | 25 | 通常の OTP が推奨されますが、新しい認証コードの「トリガー」を行うことができない場合には TOTP が推奨されます。 26 | 27 | - TOTP の例: 認証アプリ 28 | - OTP の例: Eメール、SMS 29 | 30 | ## OTP と TOTP の違いは何ですか？ 31 | 32 | 主な違いは、TOTP が時間ベースであるという点です。デバイスがサーバーに接続されていない場合に適しています。サーバーは新しい認証コードをメールアドレスや電話番号に送信することは簡単ですが、それにはメールや電話がオンラインである必要があります。しかし、認証アプリはオフラインのままで「時間」を使用して認証コードを確認できます。 33 | 34 | 35 | -------------------------------------------------------------------------------- /src/content/terms/ja/userinfo-endpoint.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Userinfo エンドポイント (Userinfo endpoint) 3 | tags: [oidc] 4 | description: Userinfo エンドポイントはクライアントにユーザー情報を提供する OpenID Connect (OIDC) エンドポイントです。これは ID トークンを補完するエンドポイントであり、クライアントが追加のユーザー情報を取得できるようにします。 5 | --- 6 | 7 | ## Userinfo エンドポイント (Userinfo endpoint) とは？ 8 | 9 | において、userinfo エンドポイントは のエンドポイントであり、クライアントにユーザー情報を提供します。userinfo エンドポイントは通常、 を補完するエンドポイントであり、クライアントが ID トークンに含まれていない追加のユーザー情報を取得できるようにします。 10 | 11 | userinfo エンドポイントは [OpenID Connect Core specification](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) に定義されており、クライアントが ID トークンを取得した後にアクセスするのが一般的です。 12 | 13 | ## Userinfo エンドポイント (Userinfo endpoint) の仕組みは？ 14 | 15 | クライアントが userinfo エンドポイントにリクエストを送信する際、 から取得したアクセストークン (access token) を含め、`GET` または `POST` HTTP メソッドを使用する必要があります。userinfo エンドポイントはアクセストークン (access token) を検証し、レスポンスでユーザー情報を返します。 16 | 17 | userinfo リクエストの非規範的な例を以下に示します： 18 | 19 | ```http 20 | GET /userinfo HTTP/1.1 21 | Host: openid-provider.example.com 22 | Authorization: Bearer some-access-token 23 | ``` 24 | 25 | userinfo エンドポイントの正確なパスは異なる OpenID プロバイダーによって異なる場合があります。プロバイダーの を参照して、userinfo エンドポイントの URL を見つけることができます。アクセストークン (access token) が有効な場合、userinfo エンドポイントは次のようにユーザー情報を返します： 26 | 27 | ```http 28 | HTTP/1.1 200 OK 29 | Content-Type: application/json 30 | 31 | { 32 | "sub": "user123", 33 | "name": "Alice", 34 | "email": "alice@foo.com", 35 | "birthdate": "1990-01-01", 36 | "address": { 37 | "street": "1234 Elm St", 38 | "city": "Springfield", 39 | "country": "US" 40 | } 41 | } 42 | ``` 43 | 44 | レスポンスには `name`、`email`、`birthdate`、`address` などのさまざまなユーザー属性が含まれる場合があります。そして通常、 よりも多くの クレーム (claims) を含んでいます。実際に返される属性は、 の設定とユーザーの同意に依存します。具体的に利用可能な属性については、OpenID プロバイダーのドキュメントを参照してください。 45 | 46 | ### 署名と暗号化 47 | 48 | userinfo レスポンスは整合性と機密性を確保するために署名および/または暗号化されることがあります。これらの保護が適用されると、userinfo エンドポイントのレスポンスは単なる JSON オブジェクトではなく、 になります。 49 | 50 | 51 | -------------------------------------------------------------------------------- /src/content/terms/ko/auth.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 인증 (Auth, disambiguation) 3 | tags: [authentication, authorization] 4 | description: '"auth"라는 용어는 종종 인증 (authentication) 또는 인가 (authorization)를 나타내는 약어로 사용됩니다. 이 개념들은 관련이 있지만 근본적으로 다릅니다.' 5 | --- 6 | 7 | ## 인증 (Auth) 8 | 9 | 이 페이지는 "auth"라는 용어에 대한 명확한 설명을 제공합니다. 이는 종종 다음의 약어로 사용됩니다: 10 | 11 | - : 신원 소유권(예: 사용자 또는 서비스)을 확인하는 과정입니다. "어떤 신원을 소유하고 있습니까?"라는 질문에 답합니다. 12 | - : 신원이 자원에 대해 수행할 수 있는 작업을 결정하는 과정입니다. "무엇을 할 수 있습니까?"라는 질문에 답합니다. 13 | 14 | > [!Note] 15 | > 때때로 인증 (authentication)과 인가 (authorization)는 각각 "AuthN"과 "AuthZ"로 불립니다. 16 | 17 | 이 두 개념은 영역에서 모두 중요하지만 근본적으로 다릅니다. 예를 들어 보겠습니다: 웹 애플리케이션 MyStorage는 파일을 업로드하고 Google Drive에 연결할 수 있습니다. 일반적인 사용자 흐름은 다음과 같습니다: 18 | 19 | ```mermaid 20 | sequenceDiagram 21 | participant User 22 | participant MyStorage 23 | participant Google 24 | autonumber 25 | 26 | User->>MyStorage: Sign in to MyStorage 27 | MyStorage->>User: Welcome, User! 28 | User->>MyStorage: Click "Connect Google Drive" 29 | MyStorage->>Google: Redirect to Google
with authorization request 30 | Google->>User: Prompt the user to sign in 31 | User->>Google: Sign in to Google 32 | Google->>User: Ask for permission to access Google Drive 33 | User->>Google: Grant access to MyStorage 34 | Google->>MyStorage: Redirect to MyStorage
with authorization data (e.g., access token) 35 | MyStorage->>Google: Access user's Google Drive using the access token 36 | ``` 37 | 38 | 이 흐름에서 사용자는 두 번의 인증 (auth) 단계를 수행합니다: 하나는 MyStorage와 함께(1단계) 그리고 다른 하나는 Google과 함께(6단계)이며; 하나의 인가 (authorization) 단계: Google Drive에 대한 접근 권한을 부여합니다(8단계). 39 | 40 | ## 어떤 뜻인가요? 41 | 42 | "auth"라는 용어를 볼 때, 그것이 인증 (authentication)을 의미하는지 인가 (authorization)를 의미하는지 명확히 하는 것이 중요합니다. 그렇지 않으면 두 프로세스 모두를 포함한다고 예상할 수 있습니다 (이 웹사이트가 하는 것처럼). 43 | 44 | 45 | -------------------------------------------------------------------------------- /src/content/terms/ko/jwe.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: JSON 웹 암호화 (JSON Web Encryption, JWE) 3 | tags: [oidc, jose] 4 | description: JSON 웹 암호화 (JWE)는 JSON 형식의 데이터를 암호화하고 복호화하는 표준 방법입니다. 종종 JSON 웹 토큰 (JWT)을 전송할 때 민감한 정보를 보호하는 데 사용됩니다. 5 | --- 6 | 7 | ## JSON 웹 암호화 (JWE)란 무엇인가? 8 | 9 | RFC 7516에 정의된 바와 같이, JSON 웹 암호화 (JWE)는 JSON 형식의 데이터를 암호화하고 복호화하는 메커니즘입니다. JWE는 데이터에 기밀성을 추가하며, 신뢰할 수 없는 네트워크를 통해 민감한 정보를 전송할 때 매우 유용합니다. 10 | 11 | JWE는 종종 JSON 웹 토큰 (JWT)과 함께 사용되어 페이로드 데이터를 보호합니다. 예를 들어, 이나 은 JWE를 사용하여 암호화되어 전송 중에 데이터가 안전하게 보호될 수 있습니다. 12 | 13 | ## JWE는 어떻게 작동하는가? 14 | 15 | JWE는 두 가지 직렬화 형식을 가집니다: compact와 JSON입니다. 각 형식은 암호화된 데이터를 표현하는 고유한 방법을 가집니다. 16 | 17 | ### Compact 직렬화 18 | 19 | compact 직렬화에서는 JWE가 점(`.`)으로 구분된 다섯 개의 Base64URL로 인코딩된 부분으로 문자열 형태로 표현됩니다. 그 다섯 부분은 다음과 같습니다: 20 | 21 | ``` 22 | {{header}}.{{encrypted-key}}.{{iv}}.{{ciphertext}}.{{tag}} 23 | ``` 24 | 25 | 각 부분의 목적은 다음과 같습니다: 26 | 27 | - `header`: 암호화 알고리즘과 키 관리에 대한 메타데이터를 포함합니다. 28 | - `encrypted-key`: 페이로드를 암호화하는 데 사용된 암호화된 콘텐츠 암호화 키 (CEK)입니다. 29 | - `iv`: 암호화 과정에서 사용된 초기화 벡터입니다. 30 | - `ciphertext`: 암호화된 페이로드 데이터입니다. 31 | - `tag`: 암호화된 데이터의 무결성을 검증하는 인증 태그입니다. 32 | 33 | ### JSON 직렬화 34 | 35 | JSON 직렬화는 더 장황하며 JWE를 표현하는 구조적인 방법을 제공합니다. JWE는 다음과 같은 속성을 가진 JSON 객체로 표현됩니다: 36 | 37 | ```json 38 | { 39 | "protected": "{{protected-header}}", 40 | "unprotected": "{{unprotected-header}}", 41 | "header": "{{header}}", 42 | "encrypted_key": "{{encrypted-key}}", 43 | "iv": "{{iv}}", 44 | "ciphertext": "{{ciphertext}}", 45 | "tag": "{{tag}}", 46 | "aad": "{{additional-authenticated-data}}" 47 | } 48 | ``` 49 | 50 | - `protected`: Base64URL로 인코딩된 보호 헤더를 포함합니다. 51 | - `unprotected`: JWE의 공유 보호되지 않은 헤더를 포함합니다. 52 | - `header`: JWE의 각 수신자별 보호되지 않은 헤더를 포함합니다. 53 | - `encrypted_key`: Base64URL로 인코딩된 암호화된 콘텐츠 암호화 키 (CEK)를 포함합니다. 54 | - `iv`: Base64URL로 인코딩된 초기화 벡터를 포함합니다. 55 | - `ciphertext`: Base64URL로 인코딩된 암호문 (암호화된 페이로드)을 포함합니다. 56 | - `tag`: Base64URL로 인코딩된 인증 태그를 포함합니다. 57 | - `aad`: Base64URL로 인코딩된 추가 인증된 데이터를 포함합니다. 58 | 59 | --- 60 | 61 | 클라이언트는 적절한 키와 알고리즘을 사용하여 JWE를 복호화할 수 있어야 합니다. 미리 통신된 키 또는 키 합의 프로토콜을 통해 파생된 키를 사용하여 JWE를 복호화할 수 있습니다. 62 | 63 | 예를 들어, 이 JWE를 사용하여 암호화될 수 있으며, 클라이언트는 OpenID 제공자의 `jwks_uri` 엔드포인트에서 얻은 적절한 키를 사용하여 이를 복호화할 수 있습니다. 64 | 65 | 66 | 67 | 74 | -------------------------------------------------------------------------------- /src/content/terms/ko/otp.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 일회용 비밀번호 (One-time password, OTP) 3 | tags: [authentication] 4 | description: 일회용 비밀번호 (OTP)는 단일 거래나 로그인 세션에 사용되는 고유하고 임시적인 코드입니다. 5 | --- 6 | 7 | ## OTP란 무엇인가요? 8 | 9 | 일회용 비밀번호 (OTP)는 단일 거래나 로그인 세션에 사용되는 고유하고 임시적인 코드입니다. 전통적인 비밀번호는 사용자가 변경할 때까지 정적이고 동일하지만, OTP는 동적이고 발행 후 몇 분 이내에 만료됩니다. 이러한 동적 특성은 OTP가 훨씬 더 안전하게 만들어 주며, 악의적인 주체에 의해 OTP가 가로채이더라도 비인가 접근의 위험을 크게 줄입니다. 10 | 11 | OTPs는 일반적으로 시간 동기화나 수학적 계산을 기반으로 한 알고리즘을 사용하여 생성되며, 각 코드가 고유하고 예측 불가능하게 만듭니다. 사용자는 OTP를 SMS, 이메일, 모바일 앱, 하드웨어 토큰을 통해 받게 됩니다. 12 | 13 | ## OTP (일회용 비밀번호)의 일반적인 사용 사례는 무엇인가요? 14 | 15 | 다음은 OTP의 주요 사용 사례입니다: 16 | 17 | ### 비밀번호 없는 로그인 18 | 19 | 많은 웹사이트와 애플리케이션이 보안을 강화하고 사용자 편의를 증대하기 위해 비밀번호 없는 로그인 옵션을 제공합니다. 사용자는 복잡한 비밀번호를 기억할 필요 없이 본인의 등록된 휴대전화 번호나 이메일로 OTP를 요청하여 신원을 인증할 수 있습니다. 이 방법은 로그인 프로세스를 단순화할 뿐만 아니라 비밀번호 관련 침해의 위험을 줄여줍니다. 20 | 21 | ### 비밀번호 복구 22 | 23 | 사용자가 비밀번호를 잊어버린 경우, OTP는 계정 복구를 위한 안전한 방법으로 사용됩니다. 사용자는 등록된 이메일이나 전화번호로 OTP를 요청하여 이를 통해 신원을 확인한 후 비밀번호를 재설정할 수 있습니다. 이 과정은 정당한 계정 소유자만이 복구 작업을 수행할 수 있도록 보장합니다. 24 | 25 | ### 다요소 인증 (MFA) 26 | 27 | OTPs는 다요소 인증 (MFA)의 중요한 구성 요소로, 사용자가 알고 있는 것 (예: 비밀번호)과 사용자가 소유한 것 (예: 모바일 기기)을 결합합니다. 사용자는 기본 비밀번호를 입력한 후 OTP를 수신하고, 이 OTP를 입력해야 접근할 수 있습니다. 이런 추가적인 보안 계층은 기본 비밀번호가 탈취되더라도 비인가 접근의 가능성을 크게 줄입니다. 28 | 29 | ### 민감한 거래 확인 30 | 31 | 온라인 뱅킹이나 고액 구매와 같은 민감한 데이터나 중요한 거래를 수반하는 활동에 있어서, OTP는 사용자 동의를 확인하는 보안 조치로 사용됩니다. 이러한 작업을 완료하기 전에 사용자의 등록된 연락 방법으로 OTP가 전송되며 거래를 완료하려면 이 OTP를 입력해야 합니다. 이는 누군가가 사용자의 계정에 접근하더라도 OTP 없이는 중요한 작업을 수행할 수 없도록 보장합니다. 32 | 33 | 34 | -------------------------------------------------------------------------------- /src/content/terms/ko/resource-owner.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 리소스 소유자 (Resource owner) 3 | tags: [oauth 2.0] 4 | description: 리소스 소유자는 보호된 리소스에 대한 접근 권한을 부여할 수 있는 주체(일반적으로 사용자)입니다. OAuth 2.0에서는 리소스 소유자가 클라이언트에게 리소스 서버에서 자신의 리소스에 대한 접근을 허가할 수 있습니다. 5 | --- 6 | 7 | ## 리소스 소유자란 무엇인가? 8 | 9 | 의 맥락에서 리소스 소유자는 보호된 리소스(예: 데이터, 파일 또는 서비스)에 대한 접근 권한을 부여할 수 있는 주체(일반적으로 사용자)입니다. 10 | 11 | 예를 들어, 웹 애플리케이션 MyApp이 사용자의 Google 드라이브에 접근하려고 합니다. 다음은 일반적인 OAuth 2.0 흐름입니다: 12 | 13 | ```mermaid 14 | sequenceDiagram 15 | participant User 16 | participant MyApp 17 | participant Google 18 | 19 | User->>MyApp: MyApp 열고
"Google 드라이브 연결" 클릭 20 | MyApp->>Google: 인증 요청과 함께 Google로 리디렉션 21 | Google->>User: Google에 로그인 22 | User->>Google: 로그인 23 | Google->>User: Google 드라이브 접근 권한 요청 24 | User->>Google: MyApp에 접근 권한 부여 25 | Google->>MyApp: 인증 데이터(예: 접근 토큰)와 함께 MyApp으로 리디렉션 26 | MyApp->>Google: 접근 토큰을 사용하여
사용자의 Google 드라이브에 접근 27 | ``` 28 | 29 | 이 흐름에서 **사용자**는 MyApp에게 자신의 Google 드라이브에 대한 접근을 부여하는 **리소스 소유자**입니다. **MyApp**은 보호된 리소스를 접근하려는 이며, **Google**은 이자 입니다. 30 | 31 | 이름에서 알 수 있듯이, 리소스 소유자는 에 있는 일부 리소스를 소유하며 의 맥락에서 클라이언트가 이를 대신 접근할 수 있도록 권한을 부여할 수 있습니다. 32 | 33 | ## 리소스 소유자가 중요한 이유는 무엇인가? 34 | 35 | 과정에서 리소스 소유자는 자신의 리소스에 대한 접근을 명시적으로 허가하거나 거부하는 주체이기 때문에 무시할 수 없습니다. 리소스 소유자의 동의는 기술적 및 준수 상 필수적입니다: 36 | 37 | - **기술적**: 리소스 소유자의 동의는 클라이언트가 리소스에 접근하기 위한 필요한 권한을 가지고 있음을 보장합니다. 모든 것이나 아무것도 아닌 접근 대신, 리소스 소유자는 클라이언트의 요청에 따라 부분적인 접근 권한을 부여할 수 있습니다. 반면에, 리소스 소유자는 언제든지 명시적으로 접근을 철회할 수도 있습니다. 이러한 접근 방식은 을 위한 명확하고 감사를 받을 수 있는 방법을 제공합니다. 38 | - **준수**: 리소스 소유자의 동의는 특히 민감한 데이터를 다룰 때 많은 관할권에서 법적 요구 사항입니다. 예를 들어, 일반 데이터 보호 규정(GDPR)은 데이터 처리 활동에 대해 데이터 주체(리소스 소유자)가 명시적인 동의를 제공해야 한다고 규정하고 있습니다. 39 | 40 | ## 리소스 소유자 vs. 리소스 서버 41 | 42 | 리소스 서버는 **보호된 리소스**를 호스팅하고 제공하는 책임을 가지고 있습니다. 그들은 접근 토큰을 검증하고 클라이언트에게 리소스를 제공합니다. 43 | 44 | 반면에 리소스 소유자는 정책에 따라 리소스 서버에 있는 보호된 리소스에 대해 전체 또는 부분적인 통제권을 가질 수 있습니다. 45 | 46 | 47 | 48 | 53 | -------------------------------------------------------------------------------- /src/content/terms/ko/role.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 역할 (Role) 3 | tags: [authorization] 4 | description: 역할은 역할 기반 접근 제어 (RBAC) 시스템의 핵심 개념으로, 사용자가 수행할 수 있는 작업을 정의하는 권한 모음으로, 사용자에게 접근 권한을 효율적으로 관리하고 할당하는 방법을 제공합니다. 5 | --- 6 | 7 | ## 역할 (Role) 8 | 9 | 역할은 의 핵심 구성 요소 중 하나입니다. 이는 사용자에게 할당할 수 있는 권한의 컨테이너로 작용하며, 사용자와 그들의 접근 권한 사이의 중개자 역할을 합니다. 10 | 11 | ```mermaid 12 | graph LR 13 | Users 14 | -->|assigned to| Roles 15 | -->|including| Permissions 16 | ``` 17 | 18 | 일반적인 역할 구조는 이름과 권한 세트를 포함합니다: 19 | 20 | ```typescript 21 | const role = { 22 | name: 'order_admin', 23 | permissions: [ 24 | 'read:orders', // 주문 세부 정보 보기 25 | 'write:orders', // 주문 수정 26 | 'read:products' // 제품 보기 27 | ] 28 | } 29 | ``` 30 | 31 | > [!Note] 32 | > 역할은 주로 권한 관리를 위해 사용됩니다. 접근 제어 구현을 위해서는 역할보다는 권한을 직접 확인하는 것이 권장됩니다. 자세한 내용은 를 참조하세요. 33 | 34 | -------------------------------------------------------------------------------- /src/content/terms/ko/scope.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 스코프 (Scope) 3 | tags: [authorization] 4 | description: 스코프 (Scope)는 애플리케이션이 사용자의 보호된 리소스에 접근하기 위해 요청하는 권한을 정의합니다. 이는 OAuth 2.0과 OIDC에서 애플리케이션이 사용자의 데이터에 접근할 수 있는 수준을 제어하는 기본 개념입니다. 5 | --- 6 | 7 | ## 스코프란 무엇인가? 8 | 9 | 및 프로토콜에서, **스코프 (Scope)**는 애플리케이션이 사용자의 리소스에 대한 접근을 제한하는 메커니즘입니다. 이는 애플리케이션이 사용자에게 요청하는 권한을 정의합니다. 10 | 11 | 스코프는 authorization server에 의해 정의된 문자열로 표현됩니다. 애플리케이션이 사용자의 리소스에 접근을 요청할 때, authorization request에서 필요한 스코프를 명시합니다. 이후 사용자는 authorization 과정에서 이러한 권한을 승인하거나 거부하도록 요청받습니다. 12 | 13 | ### 스코프를 사용하는 이유는 무엇인가? 14 | 15 | - **세분화된 access control**: 스코프는 애플리케이션이 특정 작업을 수행하는 데 필요한 권한만 요청할 수 있게 하여 무단 접근의 위험을 줄입니다. 16 | - **사용자 동의**: 스코프는 애플리케이션이 어떤 데이터를 접근하며 그 이유를 사용자가 이해할 수 있도록 도와줍니다. 17 | - **보안**: 스코프는 애플리케이션이 자신의 접근 권한을 넘어서지 않도록 하여 사용자의 데이터 보안을 강화합니다. 18 | 19 | ## 스코프는 어떻게 작동하는가? 20 | 21 | 애플리케이션이 OAuth 2.0 / OIDC authorization 프로세스를 시작할 때, authorization request에 스코프 목록을 포함시킵니다. 그런 다음 authorization server는 사용자에게 요청된 스코프를 나열한 동의 화면을 제시합니다. 사용자는 각 스코프에 대한 접근을 승인하거나 거부할 수 있습니다. 이 프로세스는 일반적으로 사용자의 리소스에 대한 접근이 필요한 제삼자 애플리케이션에서 사용됩니다. 22 | 23 | 대안적으로, 애플리케이션이 authorization server에 의해 신뢰받는 경우, 사용자는 동의를 요청받지 않을 수 있으며, 자동 동의가 이루어져 모든 요청된 스코프가 승인됩니다. 24 | 25 | ## 스코프 정의 26 | 27 | 스코프는 일반적으로 API 제공자에 의해 정의됩니다. 이것들은 다음과 같습니다: 28 | - **표준 스코프**: OAuth 2.0 사양에 의해 정의된, 여러 애플리케이션과 서비스에 의해 공유되는 일반적으로 사용되는 스코프. 예: `openid`, `profile`, `email`. 29 | - **커스텀 스코프**: 애플리케이션 또는 서비스에 고유한 요구에 맞춘 구체적인 스코프. 예: `read:orders`, `write:comments`. 30 | 31 | ## OIDC와 identity management에서 스코프는 어디에 사용될 수 있나? 32 | 33 | 스코프는 OIDC의 다양한 측면에서 사용할 수 있으며, 그 사용은 다음에 한정되지 않습니다: 34 | 35 | - **인증 (Authentication)**: 스코프는 인증 과정에서 특정 사용자 정보를 요청하는 데 사용될 수 있습니다. 예: `profile`, `email`. 36 | - **authorization**: 스코프는 특정 리소스에 대한 접근을 요청하거나 특정 작업을 수행하는 데 사용될 수 있습니다. 예: `read:orders`, `write:comments`. 37 | - **동의 (Consent)**: 스코프는 사용자에게 애플리케이션이 요청하는 권한을 알려주기 위해 동의 화면에서 제시됩니다. 38 | - **토큰 발급**: 스코프는 애플리케이션에 부여된 권한을 나타내기 위해 토큰 응답에 포함됩니다. 39 | - **토큰 검증**: 스코프는 애플리케이션이 보호된 리소스에 접근하기 위해 토큰을 제시할 때 접근 권한을 검증하는 데 사용될 수 있습니다. 40 | - **리소스 서버**: 스코프는 리소스 서버가 애플리케이션에 부여된 권한에 기반하여 access control 정책을 시행하는 데 사용됩니다. 41 | - **사용자 프로필**: 스코프는 기본적인 claim을 넘어서 추가 사용자 프로필 정보를 요청하는 데 사용될 수 있습니다. 42 | 43 | ## 모범 사례 44 | 45 | - **최소 스코프 요청**: 애플리케이션이 작동하는 데 필요한 최소한의 스코프만 요청하세요. 이는 과도한 권한의 위험을 최소화하고 사용자 신뢰를 향상시킵니다. 46 | - **스코프 사용 설명**: 각 스코프가 필요한 이유를 사용자에게 명확히 설명하세요. 투명성은 사용자 동의를 얻는 데 도움을 줍니다. 47 | - **표준 스코프 사용**: 가능할 때 표준 스코프를 활용하여 호환성을 보장하고 복잡성을 줄이세요. 48 | 49 | 50 | 51 | -------------------------------------------------------------------------------- /src/content/terms/ko/service-provider.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 서비스 제공자 (Service provider, SP) 3 | tags: [authentication, authorization] 4 | description: 서비스 제공자 (SP)는 인증 및 인가를 위해 신원 제공자 (IdP)에 의존하는 애플리케이션 또는 서비스입니다. 5 | --- 6 | 7 | ## 서비스 제공자 (SP)란 무엇인가? 8 | 9 | 영역에서 서비스 제공자 (SP) (또는 문맥에서 **의존하는 당사자**)는 에 인증 (Authentication) 및 인가 (Authorization)를 의존하는 애플리케이션 또는 서비스입니다. 사용자를 위한 서비스를 제공하고 신원 제공자가 발급한 토큰을 기반으로 한 정책을 시행하는 책임이 있습니다. 10 | 11 | ```mermaid 12 | graph LR 13 | IdP[신원 제공자] 14 | SP["서비스 제공자
(애플리케이션, 서비스, API)"] 15 | IdP -->|사용자 인증| SP 16 | IdP -->|토큰 발급| SP 17 | IdP -->|사용자 정보 제공| SP 18 | ``` 19 | 20 | ## 서비스 제공자 표준 21 | 22 | 서비스 제공자에는 엄격한 표준이 없으며, 아이덴티티 관리가 필요한 모든 유형의 애플리케이션 또는 서비스가 될 수 있습니다. 그러나 서비스 제공자는 일반적으로 의존하는 신원 제공자가 설정한 표준을 따릅니다. 예를 들어, 신원 제공자가 를 지원하는 경우, 서비스 제공자는 일반적으로 OIDC를 사용하여 인증 및 인가를 처리합니다. 23 | 24 | ## 서비스 제공자 아키텍처 25 | 26 | "서비스 제공자"라는 용어는 특정한 아키텍처나 구현을 지정하지 않습니다. 일반적으로 서비스 제공자는 신원 제공자와 등록하여 신뢰를 구축하고 안전한 통신을 가능하게 해야 합니다. 등록 과정에는 대개 메타데이터 및 클라이언트 자격 증명 교환이 포함됩니다. 27 | 28 | 예를 들어, OpenID Connect 문맥에서 서비스 제공자 메타데이터는 일반적으로 다음을 포함합니다: 29 | 30 | - **클라이언트 ID**: 서비스 제공자의 고유 식별자. 31 | - **클라이언트 비밀**: 서비스 제공자를 인증하는 데 사용되는 공유 비밀. 32 | - **리디렉트 URI**: 신원 제공자가 인증 및 인가 후 사용자를 다시 리디렉션할 URI. 33 | 34 | 등록 후, 서비스 제공자는 사용자를 신원 제공자가 지정한 엔드포인트로 리디렉션하여 프로세스를 시작할 수 있습니다. 35 | 36 | 상호 작용이 필요 없는 사용 사례를 위해 서비스 제공자가 구축될 때, 이는 종종 클라이언트로 불리며, 통신이 필요합니다. 37 | 38 | 39 | 40 | 47 | -------------------------------------------------------------------------------- /src/content/terms/ko/token-introspection.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 토큰 인트로스펙션 (Token introspection) 3 | tags: [oauth 2.0, oidc] 4 | description: 토큰 인트로스펙션 (Token introspection)은 클라이언트가 인가 서버에 질의하여 액세스 토큰을 검증하고 그 메타데이터를 가져오는 OAuth 2.0 확장 기능입니다. 5 | --- 6 | 7 | ## 토큰 인트로스펙션 (Token introspection)이란? 8 | 9 | 토큰 인트로스펙션 (Token introspection)은 [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662)에 정의된 OAuth 2.0 확장 기능으로, 클라이언트가 에게 질의하여 액세스 토큰을 검증하고 그 메타데이터를 가져올 수 있도록 합니다. 이 확장 기능은 다음과 같은 경우에 유용합니다: 10 | 11 | - 클라이언트가 실시간으로 액세스 토큰의 유효성을 확인하고자 할 때. 12 | - 액세스 토큰이 불투명 토큰일 경우(자체 포함되지 않음) 인가 서버를 통해 검증이 필요할 때. 13 | 14 | ## 토큰 인트로스펙션 (Token introspection)은 어떻게 작동하나요? 15 | 16 | 다음은 토큰 인트로스펙션 요청의 비표준 예시입니다: 17 | 18 | ```http 19 | POST /introspect HTTP/1.1 20 | Host: authorization-server.example.com 21 | Content-Type: application/x-www-form-urlencoded 22 | 23 | token=random-token-value 24 | &token_type_hint=access_token 25 | ``` 26 | 27 | `token_type_hint` 매개변수는 선택사항이며, 인트로스펙션할 토큰의 유형으로 설정해야 합니다. 액세스 토큰이 유효하면, 인가 서버는 토큰의 메타데이터를 응답으로 반환합니다: 28 | 29 | ```http 30 | HTTP/1.1 200 OK 31 | Content-Type: application/json 32 | 33 | { 34 | "active": true, 35 | "scope": "read write", 36 | "client_id": "client-id", 37 | "username": "johndoe", 38 | "token_type": "Bearer", 39 | "exp": 1634020800, 40 | "iat": 1634017200 41 | } 42 | ``` 43 | 44 | 모든 인가 서버가 토큰 인트로스펙션을 지원하는 것은 아니며, 모든 토큰이 인트로스펙션 가능하지도 않습니다. 는 다양한 요인에 따라 토큰 인트로스펙션 사용을 제한할 수 있습니다. 예를 들어, 일부 인가 서버는 JWT에 대한 인트로스펙션을 지원하지 않을 수 있습니다. 45 | 46 | ### 토큰 인트로스펙션 요청의 주요 매개변수 47 | 48 | 토큰 인트로스펙션 요청의 주요 매개변수는 다음과 같습니다: 49 | 50 | - **`token`**: 인트로스펙션할 토큰. 51 | - **`token_type_hint`**: 인트로스펙션할 토큰의 유형. `access_token` 또는 `refresh_token`일 수 있습니다. 52 | 53 | 54 | 55 | -------------------------------------------------------------------------------- /src/content/terms/ko/totp.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 시간 기반 일회용 비밀번호 (Time-based one-time password, TOTP) 3 | tags: [authentication] 4 | description: 시간 기반 일회용 비밀번호 (TOTP)는 현재 시간을 키 요소로 사용하는 알고리즘에 의해 생성된 임시의 고유 코드입니다. 5 | --- 6 | 7 | ## TOTP란 무엇인가? 8 | 9 | 시간 기반 일회용 비밀번호 (TOTP)는 현재 시간을 키 요소로 사용하는 알고리즘에 의해 생성된 임시의 고유 코드입니다. 일반적인 와 유사하게, TOTP는 한 번만 사용되지만, 고정된 수명을 가지며 일반적으로 30초에서 60초 사이입니다. 만료되면 새로운 코드가 자동으로 생성됩니다. 10 | 11 | TOTP 표준은 인터넷 엔지니어링 태스크 포스 (IETF)에 의해 [RFC 6238](https://datatracker.ietf.org/doc/html/rfc6238)로 정의되어 있으며, 다양한 2단계 인증 (2FA) 및 다단계 인증 (MFA) 시스템에서 널리 채택되고 있습니다. TOTPs는 클라이언트 (사용자 장치)와 서버 간의 동기화된 시간에 의존하기 때문에 높은 수준의 보안을 제공하며 예측하거나 재사용하기 어렵습니다. 12 | 13 | ## TOTP 작동 방식 14 | 15 | TOTP 생성 과정은 다음 단계로 이루어집니다: 16 | 17 | 1. 공유 비밀: 초기 설정 동안, 공유 비밀 키가 생성되어 클라이언트와 서버 모두에 안전하게 저장됩니다. 이 키는 보통 QR 코드로 인코딩되어 사용자들이 인증 앱을 통해 스캔합니다. 18 | 2. 시간 간격: 현재 시간이 보통 30초 간격으로 고정된 간격으로 나뉘어집니다. 19 | 3. 알고리즘 적용: 공유 비밀 키와 현재 타임스탬프가 해시 기반 알고리즘 (흔히 HMAC-SHA1)에 입력되어 고유한 숫자 코드가 생성됩니다. 20 | 4. 동기화: 클라이언트와 서버 모두 동일한 공유 비밀과 현재 타임스탬프를 사용하여 코드를 독립적으로 생성합니다. 둘 다 동기화되어 있을 때만 코드가 일치합니다. 21 | 5. 검증: 사용자가 로그인하거나 중요한 거래를 수행할 때, 인증 앱에 표시된 TOTP를 입력합니다. 서버는 내부적으로 생성된 TOTP와 비교하여 검증합니다. 22 | 23 | ## TOTP를 언제 사용해야 하나 24 | 25 | 대부분의 경우, 일반적인 OTP가 권장되지만 새로운 패스코드를 "트리거"할 수 없는 경우에는 TOTP가 권장됩니다. 26 | 27 | - TOTP 예시: 인증 앱 28 | - OTP 예시: 이메일, SMS 29 | 30 | ## OTP와 TOTP의 차이점은 무엇인가? 31 | 32 | 주요 차이점은 TOTP가 시간 기반이라는 점으로, 장치가 서버에 연결되지 않을 때 적합합니다. 서버는 이메일 주소나 전화번호로 쉽게 새로운 패스코드를 보낼 수 있지만, 이는 이메일이나 전화가 온라인이어야 합니다. 하지만 인증 앱은 오프라인으로 유지하면서 "시간"을 이용해 패스코드를 검증할 수 있습니다. 33 | 34 | 35 | -------------------------------------------------------------------------------- /src/content/terms/ko/userinfo-endpoint.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Userinfo 엔드포인트 (Userinfo endpoint) 3 | tags: [oidc] 4 | description: Userinfo 엔드포인트는 OpenID Connect (OIDC) 엔드포인트로 클라이언트에게 사용자 정보를 제공합니다. ID 토큰의 보조 엔드포인트이며, 클라이언트가 추가적인 사용자 정보를 검색할 수 있게 해줍니다. 5 | --- 6 | 7 | ## Userinfo 엔드포인트란 무엇인가? 8 | 9 | 에서, userinfo 엔드포인트는 의 엔드포인트 중 하나로, 클라이언트에게 사용자 정보를 제공합니다. userinfo 엔드포인트는 일반적으로 의 보조 엔드포인트이며, ID 토큰에 포함되지 않은 추가적인 사용자 정보를 클라이언트가 검색할 수 있게 해줍니다. 10 | 11 | Userinfo 엔드포인트는 [OpenID Connect Core 명세](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo)에 정의되어 있으며, 주로 클라이언트가 ID 토큰을 받은 후에 접근합니다. 12 | 13 | ## Userinfo 엔드포인트는 어떻게 작동하나요? 14 | 15 | 클라이언트가 userinfo 엔드포인트에 요청을 할 때, 에서 획득한 access token (액세스 토큰)을 포함해야 하며 `GET` 또는 `POST` HTTP 메서드를 사용해야 합니다. userinfo 엔드포인트는 액세스 토큰을 검증하고, 응답으로 사용자 정보를 반환합니다. 16 | 17 | 여기 비규범적인 userinfo 요청의 예시가 있습니다: 18 | 19 | ```http 20 | GET /userinfo HTTP/1.1 21 | Host: openid-provider.example.com 22 | Authorization: Bearer some-access-token 23 | ``` 24 | 25 | 다양한 OpenID Provider에서 userinfo 엔드포인트의 정확한 경로는 다를 수 있습니다. 제공자의 를 참고하여 userinfo 엔드포인트 URL을 찾을 수 있습니다. 액세스 토큰이 유효하다면, userinfo 엔드포인트는 다음과 같이 사용자 정보를 응답합니다: 26 | 27 | ```http 28 | HTTP/1.1 200 OK 29 | Content-Type: application/json 30 | 31 | { 32 | "sub": "user123", 33 | "name": "Alice", 34 | "email": "alice@foo.com", 35 | "birthdate": "1990-01-01", 36 | "address": { 37 | "street": "1234 Elm St", 38 | "city": "Springfield", 39 | "country": "US" 40 | } 41 | } 42 | ``` 43 | 44 | 응답에는 `name`, `email`, `birthdate`, `address`와 같은 다양한 사용자 속성이 포함될 수 있으며, 일반적으로 보다 많은 클레임을 포함합니다. 반환되는 실제 속성은 의 구성과 사용자의 동의에 따라 달라집니다. 특정 속성은 OpenID Provider의 문서를 참조하세요. 45 | 46 | ### 서명 및 암호화 47 | 48 | userinfo 응답은 무결성과 기밀성을 보장하기 위해 서명되거나 암호화될 수 있습니다. 이러한 보호 중 하나 또는 둘 다 적용될 경우, userinfo 엔드포인트 응답은 평문 JSON 객체가 아닌 가 됩니다. 49 | 50 | 51 | -------------------------------------------------------------------------------- /src/content/terms/nl/auth.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Auth (ondubbelzinnig) 3 | tags: [authentication, authorization] 4 | description: De term "auth" wordt vaak gebruikt als een afkorting voor authentication (verificatie) of authorization (autorisatie). Deze concepten zijn gerelateerd, maar fundamenteel verschillend. 5 | --- 6 | 7 | ## Auth 8 | 9 | Deze pagina is een uitleg voor de term "auth". Het wordt vaak gebruikt als een afkorting voor: 10 | 11 | - : Het proces van het verifiëren van de identiteitsbezit (bijvoorbeeld gebruiker of dienst). Het beantwoordt de vraag "Welke identiteit bezit je?" 12 | - : Het proces van het bepalen welke acties een identiteit kan uitvoeren op een resource. Het beantwoordt de vraag "Wat kan je doen?" 13 | 14 | > [!Opmerking] 15 | > Soms worden authentication (verificatie) en authorization (autorisatie) aangeduid als "AuthN" en "AuthZ", respectievelijk. 16 | 17 | Deze twee concepten zijn beide essentieel in het domein, maar ze zijn fundamenteel verschillend. Laten we een voorbeeld bekijken: Een webapplicatie MyStorage heeft de mogelijkheid om bestanden te uploaden en verbinding te maken met Google Drive. Een typische gebruikersstroom zou zijn: 18 | 19 | ```mermaid 20 | sequenceDiagram 21 | participant Gebruiker 22 | participant MyStorage 23 | participant Google 24 | autonumber 25 | 26 | Gebruiker->>MyStorage: Inloggen bij MyStorage 27 | MyStorage->>Gebruiker: Welkom, Gebruiker! 28 | Gebruiker->>MyStorage: Klik op "Verbind met Google Drive" 29 | MyStorage->>Google: Omleiden naar Google
met authorization request (autorisatie aanvraag) 30 | Google->>Gebruiker: Vraag de gebruiker om in te loggen 31 | Gebruiker->>Google: Inloggen bij Google 32 | Google->>Gebruiker: Vraag om toestemming om toegang tot Google Drive 33 | Gebruiker->>Google: Verleen toegang aan MyStorage 34 | Google->>MyStorage: Omleiden naar MyStorage
met authorization data (bijv. access token) 35 | MyStorage->>Google: Toegang tot de Google Drive van de gebruiker met de access token 36 | ``` 37 | 38 | In deze stroom voert de gebruiker twee authentication (verificatie) stappen uit: één met MyStorage (stap 1) en een andere met Google (stap 6); en één authorization (autorisatie) stap: toegang verlenen tot Google Drive (stap 8). 39 | 40 | ## Welke bedoel je? 41 | 42 | Wanneer je de term "auth" ziet, is het belangrijk om te verduidelijken of het verwijst naar authentication (verificatie) of authorization (autorisatie); anders zou je kunnen verwachten dat beide processen worden behandeld (net zoals deze website doet). 43 | 44 | -------------------------------------------------------------------------------- /src/content/terms/nl/role.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Rol 3 | tags: [authorization] 4 | description: Een rol is een kernconcept in systemen voor op rollen gebaseerde toegangscontrole (RBAC), dat een verzameling machtigingen vertegenwoordigt die bepalen welke acties gebruikers kunnen uitvoeren, en biedt een efficiënte manier om toegangsrechten aan gebruikers te beheren en toe te wijzen. 5 | --- 6 | 7 | ## Rol 8 | 9 | Een rol is een van de kernelementen in . Het dient als een container voor machtigingen die aan gebruikers kunnen worden toegewezen en fungeert als een tussenpersoon tussen gebruikers en hun toegangsrechten. 10 | 11 | ```mermaid 12 | graph LR 13 | Gebruikers 14 | -->|toegewezen aan| Rollen 15 | -->|inclusief| Machtigingen 16 | ``` 17 | 18 | Een typische rolstructuur bevat een naam en een set machtigingen: 19 | 20 | ```typescript 21 | const role = { 22 | name: 'order_admin', 23 | permissions: [ 24 | 'read:orders', // Bekijk bestelgegevens 25 | 'write:orders', // Bewerk bestellingen 26 | 'read:products' // Bekijk producten 27 | ] 28 | } 29 | ``` 30 | 31 | > [!Opmerking] 32 | > Rollen worden voornamelijk gebruikt voor machtigingsbeheer. Voor de implementatie van toegangscontrole wordt aanbevolen om machtigingen direct te controleren in plaats van rollen. Zie voor meer informatie. 33 | 34 | -------------------------------------------------------------------------------- /src/content/terms/pt-br/auth.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Auth (desambiguação) 3 | tags: [authentication, authorization] 4 | description: O termo "auth" é frequentemente usado como uma abreviação para authentication (autenticação) ou authorization (autorização). Esses conceitos estão relacionados, mas são fundamentalmente diferentes. 5 | --- 6 | 7 | ## Auth 8 | 9 | Esta página é uma desambiguação para o termo "auth". Ele é frequentemente usado como uma abreviação para: 10 | 11 | - : O processo de verificar a propriedade da identidade (por exemplo, usuário ou serviço). Responde à pergunta "Qual identidade você possui?" 12 | - : O processo de determinar quais ações uma identidade pode realizar em um recurso. Responde à pergunta "O que você pode fazer?" 13 | 14 | > [!Note] 15 | > Às vezes, authentication (autenticação) e authorization (autorização) são referidos como "AuthN" e "AuthZ", respectivamente. 16 | 17 | Esses dois conceitos são essenciais no domínio de , mas são fundamentalmente diferentes. Vamos ver um exemplo: Um aplicativo web MyStorage tem a capacidade de fazer upload de arquivos e se conectar ao Google Drive. Um fluxo típico de usuário seria: 18 | 19 | ```mermaid 20 | sequenceDiagram 21 | participant Usuário 22 | participant MyStorage 23 | participant Google 24 | autonumber 25 | 26 | Usuário->>MyStorage: Entrar no MyStorage 27 | MyStorage->>Usuário: Bem-vindo, Usuário! 28 | Usuário->>MyStorage: Clicar em "Conectar Google Drive" 29 | MyStorage->>Google: Redirecionar para o Google
com authorization request 30 | Google->>Usuário: Solicitar que o usuário faça login 31 | Usuário->>Google: Entrar no Google 32 | Google->>Usuário: Pedir permissão para acessar o Google Drive 33 | Usuário->>Google: Conceder acesso ao MyStorage 34 | Google->>MyStorage: Redirecionar para o MyStorage
com dados de autorização (por exemplo, access token) 35 | MyStorage->>Google: Acessar o Google Drive do usuário usando o access token 36 | ``` 37 | 38 | Neste fluxo, o usuário realiza duas etapas de authentication (autenticação): uma com o MyStorage (passo 1) e outra com o Google (passo 6); e uma etapa de authorization (autorização): concedendo acesso ao Google Drive (passo 8). 39 | 40 | ## Qual você quer dizer? 41 | 42 | Quando você vê o termo "auth", é importante esclarecer se está se referindo a authentication (autenticação) ou authorization (autorização); caso contrário, você pode esperar que ambos os processos sejam abordados (assim como este site faz). 43 | 44 | -------------------------------------------------------------------------------- /src/content/terms/pt-br/role.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Papel (Role) 3 | tags: [authorization] 4 | description: Um papel (role) é um conceito central em sistemas de controle de acesso baseado em papéis (RBAC), representando uma coleção de permissões que define quais ações os usuários podem realizar, proporcionando uma maneira eficiente de gerenciar e atribuir direitos de acesso aos usuários. 5 | --- 6 | 7 | ## Papel (Role) 8 | 9 | Um papel (role) é um dos componentes centrais em . Ele serve como um contêiner para permissões que podem ser atribuídas a usuários, atuando como um intermediário entre os usuários e seus direitos de acesso. 10 | 11 | ```mermaid 12 | graph LR 13 | Usuários 14 | -->|atribuído a| Papéis 15 | -->|incluindo| Permissões 16 | ``` 17 | 18 | Uma estrutura típica de papel (role) contém um nome e um conjunto de permissões: 19 | 20 | ```typescript 21 | const role = { 22 | name: 'order_admin', 23 | permissions: [ 24 | 'read:orders', // Ver detalhes do pedido 25 | 'write:orders', // Editar pedidos 26 | 'read:products' // Ver produtos 27 | ] 28 | } 29 | ``` 30 | 31 | > [!Note] 32 | > Papéis (roles) são usados principalmente para gerenciamento de permissões. Para implementação de controle de acesso, é recomendado verificar permissões diretamente em vez de papéis. Veja para mais informações. 33 | 34 | -------------------------------------------------------------------------------- /src/content/terms/pt-pt/auth.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Auth (desambiguação) 3 | tags: [authentication, authorization] 4 | description: O termo "auth" é frequentemente usado como uma abreviação para authentication (autenticação) ou authorization (autorização). Esses conceitos estão relacionados, mas são fundamentalmente diferentes. 5 | --- 6 | 7 | ## Auth 8 | 9 | Esta página é uma desambiguação para o termo "auth". Ele é frequentemente usado como uma abreviação para: 10 | 11 | - : O processo de verificar a propriedade da identidade (por exemplo, usuário ou serviço). Responde à pergunta "Qual identidade você possui?" 12 | - : O processo de determinar quais ações uma identidade pode realizar em um recurso. Responde à pergunta "O que você pode fazer?" 13 | 14 | > [!Note] 15 | > Às vezes, authentication (autenticação) e authorization (autorização) são referidos como "AuthN" e "AuthZ", respectivamente. 16 | 17 | Esses dois conceitos são ambos essenciais no domínio de , mas são fundamentalmente diferentes. Vamos ver um exemplo: Uma aplicação web MyStorage tem a capacidade de fazer upload de arquivos e conectar-se ao Google Drive. Um fluxo típico de usuário seria: 18 | 19 | ```mermaid 20 | sequenceDiagram 21 | participant User 22 | participant MyStorage 23 | participant Google 24 | autonumber 25 | 26 | User->>MyStorage: Iniciar sessão no MyStorage 27 | MyStorage->>User: Bem-vindo, Usuário! 28 | User->>MyStorage: Clicar em "Conectar Google Drive" 29 | MyStorage->>Google: Redirecionar para o Google
com authorization request 30 | Google->>User: Solicitar ao usuário para iniciar sessão 31 | User->>Google: Iniciar sessão no Google 32 | Google->>User: Pedir permissão para acessar o Google Drive 33 | User->>Google: Conceder acesso ao MyStorage 34 | Google->>MyStorage: Redirecionar para o MyStorage
com dados de autorização (por exemplo, access token) 35 | MyStorage->>Google: Acessar o Google Drive do usuário usando o access token 36 | ``` 37 | 38 | Neste fluxo, o usuário realiza dois passos de authentication (autenticação): um com o MyStorage (passo 1) e outro com o Google (passo 6); e um passo de authorization (autorização): concedendo acesso ao Google Drive (passo 8). 39 | 40 | ## A qual você se refere? 41 | 42 | Quando você vê o termo "auth", é importante esclarecer se está se referindo a authentication (autenticação) ou authorization (autorização); caso contrário, você pode esperar que ambos os processos sejam abordados (assim como este site faz). 43 | 44 | -------------------------------------------------------------------------------- /src/content/terms/pt-pt/role.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Papel (Role) 3 | tags: [authorization] 4 | description: Um papel (role) é um conceito central em sistemas de controlo de acesso baseado em papéis (RBAC), representando uma coleção de permissões que define quais ações os utilizadores podem realizar, proporcionando uma forma eficiente de gerir e atribuir direitos de acesso aos utilizadores. 5 | --- 6 | 7 | ## Papel (Role) 8 | 9 | Um papel (role) é um dos componentes centrais em . Serve como um contêiner para permissões que podem ser atribuídas a utilizadores, atuando como um intermediário entre os utilizadores e os seus direitos de acesso. 10 | 11 | ```mermaid 12 | graph LR 13 | Utilizadores 14 | -->|atribuído a| Papéis 15 | -->|incluindo| Permissões 16 | ``` 17 | 18 | Uma estrutura típica de papel (role) contém um nome e um conjunto de permissões: 19 | 20 | ```typescript 21 | const role = { 22 | name: 'order_admin', 23 | permissions: [ 24 | 'read:orders', // Ver detalhes do pedido 25 | 'write:orders', // Editar pedidos 26 | 'read:products' // Ver produtos 27 | ] 28 | } 29 | ``` 30 | 31 | > [!Note] 32 | > Os papéis (roles) são usados principalmente para gestão de permissões. Para a implementação de controlo de acesso, é recomendado verificar as permissões diretamente em vez dos papéis. Veja para mais informações. 33 | 34 | -------------------------------------------------------------------------------- /src/content/terms/zh-Hant/auth.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 認證 (Auth)（消歧義） 3 | tags: [authentication, authorization] 4 | description: '"auth" 這個詞常用作認證 (authentication) 或授權 (authorization) 的縮寫。這些概念相關但本質上不同。' 5 | --- 6 | 7 | ## 認證 (Auth) 8 | 9 | 這個頁面是針對 "auth" 這個詞的消歧義。它常用作以下的縮寫： 10 | 11 | - ：驗證身份所有權的過程（例如，使用者或服務）。它回答 "你擁有哪個身份？" 12 | - ：決定一個身份可以對資源執行哪些操作的過程。它回答 "你可以做什麼？" 13 | 14 | > [!Note] 15 | > 有時，認證 (authentication) 和授權 (authorization) 分別被稱為 "AuthN" 和 "AuthZ"。 16 | 17 | 這兩個概念都是 領域中不可或缺的，但它們本質上是不同的。讓我們看看一個例子：一個名為 MyStorage 的網頁應用有上傳文件和連接到 Google Drive 的功能。典型的使用者流程如下： 18 | 19 | ```mermaid 20 | sequenceDiagram 21 | participant 使用者 22 | participant MyStorage 23 | participant Google 24 | autonumber 25 | 26 | 使用者->>MyStorage: 登入 MyStorage 27 | MyStorage->>使用者: 歡迎, 使用者! 28 | 使用者->>MyStorage: 點擊“連接 Google Drive” 29 | MyStorage->>Google: 重定向到 Google
帶有授權請求 (authorization request) 30 | Google->>使用者: 提示使用者登入 31 | 使用者->>Google: 登入 Google 32 | Google->>使用者: 申請訪問 Google Drive 的許可 33 | 使用者->>Google: 授予 MyStorage 訪問權限 34 | Google->>MyStorage: 重定向到 MyStorage
帶有授權數據（例如，訪問令牌 (access token)） 35 | MyStorage->>Google: 使用訪問令牌訪問使用者的 Google Drive 36 | ``` 37 | 38 | 在此流程中，使用者進行了兩次認證 (authentication) 步驟：一次是在 MyStorage (步驟 1)，一次是在 Google (步驟 6)；以及一次授權 (authorization) 步驟：授予 Google Drive 的訪問權限 (步驟 8)。 39 | 40 | ## 你的意思是哪一個？ 41 | 42 | 當你看到 "auth" 這個詞時，重要的是要明確它是指認證 (authentication)還是授權 (authorization)；否則，你可能期望兩個過程都涵蓋在內（就像這個網站一樣）。 43 | 44 | 45 | -------------------------------------------------------------------------------- /src/content/terms/zh-Hant/authorization.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 授權 (Authorization) 3 | tags: [authorization] 4 | description: 授權 (Authorization) 是確定一個身份可以在資源上執行哪些操作的過程。這是一種基本的安全機制，用於定義和實施訪問策略。 5 | --- 6 | 7 | ## 什麼是授權 (Authorization)？ 8 | 9 | > **簡而言之**：授權 (Authorization) 解答了「你能做什麼？」這個問題。 10 | 11 | 授權 (Authorization) 是一個決策過程，用來確定一個身份（用戶、服務或設備）是否擁有必要的權限以對資源執行特定操作。我們來看看一些例子： 12 | 13 | - 在一個線上文檔編輯器中，用戶可以與其他人共享文檔。 14 | - 在一個雲存儲服務中，服務可以在特定文件夾中讀寫文件。 15 | - 在一個智慧家庭系統中，設備可以開啟客廳的燈光。 16 | 17 | 所有這些例子都涉及一個身份（主體）在資源上執行操作。當然，授權 (Authorization) 也可能失敗，例如當一個用戶嘗試刪除他們無權訪問的文件時。 18 | 19 | 授權 (Authorization) 的基本模型很簡單：如果 **身份** 在 **資源** 上執行 **操作**，則 **接受** 或 **拒絕**。 20 | 21 | ### 認證 (Authentication) 和授權 (Authorization) 的區別 22 | 23 | 認證 (Authentication) 和授權 (Authorization) 常常被混淆，但它們本質上是不同的： 解答了「你擁有哪個身份？」這個問題。此外，在大多數情況下，授權 (Authorization) 發生在認證 (Authentication) 之後，因為系統需要知道身份才能做出訪問決策。 24 | 25 | ### 授權 (Authorization) 和訪問控制 (Access Control) 的區別 26 | 27 | 授權 (Authorization) 是訪問控制 (Access Control) 的一個子集。訪問控制 (Access Control) 是包括授權 (Authorization) 和其他訪問管理限制的更廣泛概念。換句話說，訪問控制 (Access Control) 是一個描述對資源的選擇性限制的通用術語，而授權 (Authorization) 特指決策過程。 28 | 29 | ## 授權 (Authorization) 是如何運作的？ 30 | 31 | 授權 (Authorization) 通常使用 來實現。它們定義了如何在系統中分配和執行權限。 32 | 33 | ## 授權框架 (Authorization Frameworks)（協議） 34 | 35 | 雖然 是一個非常流行的授權 (Authorization) 框架，但值得注意的是 OAuth 2.0 並未定義使用哪種訪問控制 (Access Control) 模型。相反，它專注於授權 (Authorization) 的委託和訪問令牌的發行。 36 | 37 | 也就是說，OAuth 2.0 適用於用戶授權客戶端訪問其資源的第三方授權 (Authorization) 場景。例如，當你使用 Google 帳戶登錄網站時，你是在授權 (Authorization) 該網站訪問你的 Google 個人資料。 38 | 39 | 如果你處理的是第一方授權 (Authorization)（例如你的應用程序或組織內），則可能需要實施一種訪問控制 (Access Control) 模型，例如 或 。 和訪問控制 (Access Control) 模型的結合能為認證 (Authentication) 和授權 (Authorization) 提供堅實的基礎。 40 | 41 | 與其構建一個自製的授權 (Authorization) 系統，建議使用提供認證 (Authentication) 和授權 (Authorization) 功能的 。一個好的身份提供者將處理訪問控制 (Access Control) 的複雜性，並為你的應用程序提供一個安全且可擴展的解決方案。 42 | 43 | 44 | 45 | -------------------------------------------------------------------------------- /src/content/terms/zh-Hant/claim.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 聲明 (Claim) 3 | tags: [oauth 2.0, oidc] 4 | description: 在 JSON Web Token (JWT) 中，聲明 (claim) 是一個名稱值對，用來傳達特定資訊。在更廣泛的上下文中，聲明可以是任何表示資訊的名稱值對。 5 | --- 6 | 7 | ## 什麼是聲明 (claim)？ 8 | 9 | 聲明 (claim) 是一個用來傳達特定資訊的名稱值對。比如，在一個 JSON 對象中： 10 | 11 | ```json 12 | { 13 | "sub": "foo", 14 | "email": "foo@bar.com" 15 | } 16 | ``` 17 | 18 | 在這個例子中，`sub` 是一個表示主體識別碼的聲明，值為 `foo`，`email` 是一個表示電子郵件地址的聲明，值為 `foo@bar.com`。 19 | 20 | > 我們使用 *subject* 而不是 *user*，因為如果沒有明確定義，主體 (`sub`) 可以表示用戶、設備或任何實體。 21 | 22 | ### 聲明的用途 23 | 24 | 聲明廣泛用於各種上下文中，例如： 25 | 26 | - : 在 JWT 中，聲明用於表示有關 token 的資訊，例如發行者 (`iss`)、主體 (`sub`) 和過期時間 (`exp`)。 27 | - : 在 OIDC 中，聲明用於表示用戶資訊，如 和 中的用戶電子郵件地址 (`email`)、姓名 (`name`) 和頭像 (`picture`)。 28 | 29 | ### 標準聲明 30 | 31 | 在 JWT 和 OIDC 中，規範定義了一些標準聲明。常見的標準聲明包括： 32 | 33 | - **`iss`**: token 的發行者。例如，如果發行 token 的 是 `https://example.com`，那麼在大多數情況下 `iss` 聲明將是相同的 (`https://example.com`)。 34 | - **`sub`**: token 的主體。它表示 token 所涉及的實體。例如，在 ID token 中，`sub` 聲明通常表示用戶識別碼。 35 | - **`aud`**: token 的受眾。它表明 token 所針對的接收者。例如，如果 token 是為了訪問位於 `https://api.example.com` 的 API，那麼 `aud` 聲明將是相同的 (`https://api.example.com`)。 36 | - **`exp`**: token 的過期時間。它表明 token 何時不應再被接受處理。 37 | - **`nbf`**: token 的 "not before" (不早於) 時間。它表明 token 何時開始被接受處理。 38 | - **`iat`**: token 的簽發時間。它表明 token 的發行時間。 39 | - **`jti`**: token 的 JWT ID。它為 token 提供一個唯一識別碼。 40 | 41 | OIDC 還定義了其他用于用戶資訊的標準聲明。請參見 OIDC 規範中的 [Claims](https://openid.net/specs/openid-connect-core-1_0.html#Claims) 獲取更多詳情。 42 | 43 | ### 自定義聲明 44 | 45 | 除了標準聲明外，你可以定義自定義聲明來表示應用程式特定的資訊。例如，你可以包含一個 `role` 聲明來表示用戶在應用程式中的角色。 46 | 47 | 自定義聲明可以用 [統一資源標識符 (URI)](https://blog.logto.io/unveiling-uri-url-and-urn) 命名空間來避免與其他聲明衝突。例如： 48 | 49 | ```json 50 | { 51 | "https://example.com/claims/role": "admin" 52 | } 53 | ``` 54 | 55 | 在這個例子中，`role` 聲明用 `https://example.com/claims/` 命名空間來確保唯一性。另外，你可以為自定義聲明定義自己的 [統一資源名稱 (URN)](https://blog.logto.io/unveiling-uri-url-and-urn)： 56 | 57 | ```json 58 | { 59 | "urn:example:claims:role": "admin" 60 | } 61 | ``` 62 | 63 | 在這個例子中，`role` 聲明用 `urn:example:claims:` 命名空間。 64 | 65 | 66 | 67 | -------------------------------------------------------------------------------- /src/content/terms/zh-Hant/jwe.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: JSON 網路加密 (JSON Web Encryption, JWE) 3 | tags: [oidc, jose] 4 | description: JSON 網路加密 (JWE) 是一種加密和解密 JSON 格式數據的標準方式。它經常用於保護傳輸中的 JSON 網路令牌 (JWT) 中的敏感信息。 5 | --- 6 | 7 | ## 什麼是 JSON 網路加密 (JWE)？ 8 | 9 | 根據 RFC 7516 的定義，JSON 網路加密 (JWE) 是一種加密和解密 JSON 格式數據的機制。它為數據添加了一層保密性，特別是在不受信任的網絡上傳輸敏感信息時非常有用。 10 | 11 | JWE 通常與 JSON 網路令牌 (JWT) 一起使用，以保護有效負載數據。例如，一個 或 可以使用 JWE 加密，以確保數據在傳輸過程中的安全性。 12 | 13 | ## JWE 如何運作？ 14 | 15 | JWE 有兩種序列化格式：緊湊和 JSON。每種格式都有自己的方式來表示加密數據。 16 | 17 | ### 緊湊序列化 18 | 19 | 在緊湊序列化中，JWE 表示為一個由點 (`.`) 分隔的五段 Base64URL 編碼的字符串。這五段是： 20 | 21 | ``` 22 | {{header}}.{{encrypted-key}}.{{iv}}.{{ciphertext}}.{{tag}} 23 | ``` 24 | 25 | 每段都有特定的目的： 26 | 27 | - `header`: 包含關於加密算法和密鑰管理的元數據。 28 | - `encrypted-key`: 用於加密有效負載的加密內容加密密鑰 (CEK)。 29 | - `iv`: 加密過程中使用的初始化向量。 30 | - `ciphertext`: 加密的有效負載數據。 31 | - `tag`: 用於驗證加密數據完整性的認證標籤。 32 | 33 | ### JSON 序列化 34 | 35 | JSON 序列化更詳細，提供了一種結構化的方式來表示 JWE。JWE 表示為具有以下屬性的 JSON 對象： 36 | 37 | ```json 38 | { 39 | "protected": "{{protected-header}}", 40 | "unprotected": "{{unprotected-header}}", 41 | "header": "{{header}}", 42 | "encrypted_key": "{{encrypted-key}}", 43 | "iv": "{{iv}}", 44 | "ciphertext": "{{ciphertext}}", 45 | "tag": "{{tag}}", 46 | "aad": "{{additional-authenticated-data}}" 47 | } 48 | ``` 49 | 50 | - `protected`: 包含 Base64URL 編碼的受保護標頭。 51 | - `unprotected`: 包含 JWE 共享的未保護標頭。 52 | - `header`: 包含 JWE 每個接收者的未保護標頭。 53 | - `encrypted_key`: 包含 Base64URL 編碼的加密內容加密密鑰 (CEK)。 54 | - `iv`: 包含 Base64URL 編碼的初始化向量。 55 | - `ciphertext`: 包含 Base64URL 編碼的密文 (加密的有效負載)。 56 | - `tag`: 包含 Base64URL 編碼的認證標籤。 57 | - `aad`: 包含 Base64URL 編碼的附加認證數據。 58 | 59 | --- 60 | 61 | 客戶端應能夠使用適當的密鑰和算法解密 JWE。可以使用預先協商的密鑰或通過密鑰協商協議導出的密鑰來解密 JWE。 62 | 63 | 例如，一個 可能會使用 JWE 加密，客戶端可以使用從 OpenID 供應商的 `jwks_uri` 端點獲得的適當密鑰來解密它。 64 | 65 | 66 | 67 | 74 | -------------------------------------------------------------------------------- /src/content/terms/zh-Hant/management-api.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 管理 API (Management API) 3 | tags: [api, integration] 4 | description: 在身份與存取管理 (IAM) 的背景下，管理 API 允許對使用者、應用程式、角色和權限等資源進行程式化管理。通常是 RESTful 的，它在 IAM 系統和使用者介面之間提供了一個抽象層，實現自動化、整合和自訂功能開發。 5 | --- 6 | 7 | ## 什麼是管理 API？ 8 | 9 | 管理 API 的定義可能因使用的軟體或服務而異。在身份與存取管理 (IAM) 的背景下，管理 API 通常是指一組可以程式化管理 IAM 相關資源的 API。例如，使用者、應用程式、角色、權限、組織等。 10 | 11 | 儘管名稱未明確指定具體實現，但管理 API 通常是 RESTful 的，因為它能精確定義可在資源上執行的操作。因此，當你看到 `POST /users` 時，你可以預期這個 API 調用會創建一個新使用者。 12 | 13 | ## 為什麼管理 API 很重要？ 14 | 15 | 管理 API 在 IAM 系統上創建了一個單獨的抽象層，但位於使用者介面下方。這使開發人員能夠自動化 IAM 資源的管理，這在多種情境下尤其有用： 16 | 17 | ### 1. 自動化 18 | 19 | 如其名所示，管理 API 允許你使用程式碼來管理資源，而不是通過使用者介面手動點擊。這在你需要管理大量使用者、應用程式或角色時特別有用。例如，你可以編寫腳本從 CSV 文件匯入使用者，並為他們分配正確的角色和權限。 20 | 21 | ### 2. 整合 22 | 23 | 管理 API 為服務對服務（或機器對機器 (machine-to-machine)）通信創建了一種標準方式。當你擁有多個需要與 IAM 系統通信的服務時，與其為每個服務實現自訂整合，不如設計一個良好的管理 API，通過 API 調用可適用於所有服務。例如，一個需要列出特定角色下所有使用者的服務，可以通過調用 `GET /roles/{role_id}/users` 來實現。 24 | 25 | ### 3. 組合和功能擴展 26 | 27 | 由於業務需求的多樣性，IAM 系統可能無法提供所有你需要的精確功能，特別是當涉及複雜的訪問控制 (access control) 要求時。管理 API 允許你在現有 IAM 系統之上構建自訂功能，而無需修改基礎平台或架構。 28 | 29 | 讓我們看一個日常例子：終端使用者需要更改他們的電子郵件地址。不同的應用程序可能有不同的要求： 30 | 31 | 1. 應用程序 A 要求使用者驗證舊的和新的電子郵件地址。 32 | 2. 應用程序 B 要求使用者在更改電子郵件地址之前驗證現有密碼。 33 | 3. 應用程序 C 要求使用者驗證現有密碼並要求管理員批准更改電子郵件地址。 34 | 35 | 使用管理 API，你可以構建一個自訂服務，通過調用必要的 API 以正確的順序來協調這些要求。你甚至可以將管理 API 與你的服務的 API 結合起來，以實現複雜的工作流程。以應用程序 C 為例： 36 | 37 | 1. 使用者在應用程序 C 中點擊「更改電子郵件」，這會向你的服務發送請求 `POST /email-change-requests`。它會創建一個新的電子郵件更改請求並返回識別符 `foo`。 38 | 2. 應用程序 C 向使用者顯示一個對話框，要求他們輸入現有的密碼。 39 | 3. 使用者輸入密碼，應用程序 C 向你的服務發送請求 `PATCH /email-change-requests/foo`，附帶密碼。在背景中，你的服務會通過調用管理 API `POST /users/{user_id}/verify-password` 驗證密碼。 40 | 4. 如果密碼正確，你的服務會在電子郵件更改請求 `foo` 中創建一條成功驗證記錄。 41 | 5. 在管理面板中，管理員可以使用 `GET /email-change-requests?status=pending` 查看待處理的電子郵件更改請求。 42 | 6. 如果管理員批准請求，管理面板會向你的服務發送請求 `PATCH /email-change-requests/foo`，附帶管理員的批准。 43 | 7. 然後你的服務會調用管理 API `PATCH /users/{user_id}` 來更新使用者的電子郵件地址。如果無法更新電子郵件地址，管理 API 將返回錯誤，你的服務可相應地處理它。 44 | 45 | 注意在上述例子中，我們的終端使用者從未直接與管理 API 互動。相反，他們與應用程序 C 互動，而應用程序 C 在背景中協同管理 API 調用以實現所需的工作流程。 46 | 47 | ## 優秀的管理 API 應該是什麼樣的？ 48 | 49 | - **RESTful**：遵循 RESTful 原則，使 API 預測性強且易於使用。 50 | - **以資源為導向**：將資源表示為名詞，並使用 HTTP 方法對它們執行操作。 51 | - **一致性**：使用一致的命名約定、錯誤處理和響應格式。 52 | - **安全性**：實施適當的認證 (authentication) 和授權 (authorization) 機制以保護 API。 53 | - **文件化**：提供清晰明確的文件說明 API 的使用方法，包括示例和用例。 54 | - **兼容性**：在引入 API 的新版本時確保向後兼容。 55 | - **全面性**：涵蓋所有必要的操作以有效地管理 IAM 資源。 56 | 57 | 還有其他方面，如性能和可擴展性，更多與基礎設施相關，而不是 API 設計本身。然而，在實踐中，一個好的管理 API 應考慮這些方面。 58 | 59 | 66 | -------------------------------------------------------------------------------- /src/content/terms/zh-Hant/offline-access.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 離線存取 (Offline access) 3 | tags: [oauth 2.0, oidc] 4 | description: 離線存取 (Offline access) 允許客戶端在不需要用戶重新認證 (authenticate) 的情況下獲取新的訪問 (access) 令牌，這對於長期會話和更好的用戶體驗非常有用。 5 | --- 6 | 7 | ## 什麼是離線存取 (Offline access)？ 8 | 9 | 離線存取 (Offline access) 的概念可能因情境而異，我們將專注於 OAuth 2.0 和 OpenID Connect (OIDC) 規範。在這個情境中，離線存取允許客戶端使用刷新 (refresh) 令牌獲取新的訪問 (access) 令牌，而無需用戶重新認證 (authenticate)。此功能特別有助於長期會話和改善用戶體驗。 10 | 11 | 值得注意的是，OAuth 2.0 並未明確定義「離線存取 (offline access)」這一術語；它只規定使用刷新 (refresh) 令牌來獲取新的訪問 (access) 令牌。但是，「離線存取 (offline access)」這一術語（以及 `offline_access` scope）已在業界廣泛採用來指代此功能，並在規範中得到正式定義。 12 | 13 | ## 離線存取 (Offline access) 如何運作？ 14 | 15 | 為了簡化，我們將使用 OAuth 2.0 術語和來說明離線存取 (offline access) 的運作方式。在 OIDC 中，這些術語的替代詞分別是和。 16 | 17 | 離線存取 (Offline access) 涉及兩個主要步驟： 18 | 19 | 1. **請求離線存取**：當向授權伺服器發起授權 (authorization) 請求時，包含 `offline_access` scope 以請求離線存取。此 scope 表明客戶端希望獲取刷新 (refresh) 令牌以及訪問 (access) 令牌。 20 | 21 | 對於離線存取 (offline access) 的支援可能因授權伺服器而異，如果授權伺服器不支援此功能，可能會忽略 `offline_access` scope。請參閱授權伺服器的文件以確保在使用此 scope 前的相容性。 22 | 23 | 2. **使用刷新 (refresh) 令牌**：一旦完成，客戶端應該收到一個刷新 (refresh) 令牌和一個訪問 (access) 令牌。客戶端可以安全地存儲刷新 (refresh) 令牌，並在當前訪問 (access) 令牌過期時，使用它向授權伺服器發送以獲取新的訪問 (access) 令牌。 24 | 25 | 有關離線存取 (offline access) 實際操作的詳細範例，請參閱文章。 26 | 27 | ## 安全考量 28 | 29 | 離線存取 (Offline access) 的安全影響類似於刷新 (refresh) 令牌。請參閱刷新 (refresh) 令牌的部分以獲取詳細信息。 30 | 31 | 32 | 33 | -------------------------------------------------------------------------------- /src/content/terms/zh-Hant/otp.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 一次性密碼 (One-time password, OTP) 3 | tags: [authentication] 4 | description: 一次性密碼 (OTP) 是一個唯一的、臨時的代碼，用於單次交易或登入會話。 5 | --- 6 | 7 | ## 什麼是 OTP？ 8 | 9 | 一次性密碼 (OTP) 是一個唯一的、臨時的代碼，用於單次交易或登入會話。與傳統密碼不同，傳統密碼是靜態且保持不變直至用戶更改，而 OTP 是動態的，並且在發行後會很快過期，通常在幾分鐘內。由於這種動態特性，即使 OTP 被惡意方攔截，也能大大降低未經授權的存取風險，使 OTP 更加安全。 10 | 11 | OTP 通常通過基於時間同步或數學計算的算法生成，確保每個代碼都是唯一且無法預測的。用戶通常通過 SMS、電子郵件、移動應用程式或硬件代碼接收 OTP。 12 | 13 | ## OTP（一次性密碼）的常見使用案例有哪些？ 14 | 15 | 以下是 OTP 的一些主要用途： 16 | 17 | ### 無密碼登入 18 | 19 | 許多網站和應用程式現在提供無密碼登入選項，以增強安全性和用戶便利性。用戶可以請求發送 OTP 到註冊的手機號碼或電子郵件，以驗證自己的身份，無需記住複雜的密碼。這種方法不僅簡化了登入過程，還降低了與密碼相關的安全漏洞風險。 20 | 21 | ### 密碼恢復 22 | 23 | 在用戶忘記密碼的情況下，OTP 可用作帳戶恢復的安全方法。用戶可以請求 OTP，該代碼會發送到註冊的電子郵件或電話號碼，以驗證身份後重設密碼。此過程有助於確保只有合法的帳戶擁有者可以執行恢復操作。 24 | 25 | ### 多因素認證 (MFA) 26 | 27 | OTP 是多因素認證 (MFA) 的重要組成部分，多因素認證結合了用戶知道的東西（如密碼）和用戶擁有的東西（如移動設備）。在輸入主密碼後，用戶會收到 OTP，必須輸入該代碼才能獲得存取權。即使主要密碼被洩露，此額外的安全層也大大降低了未經授權存取的可能性。 28 | 29 | ### 敏感交易確認 30 | 31 | 對於涉及敏感數據或重大交易的活動，例如網上銀行或高價值購買，OTP 作為確認用戶同意的安全措施。在完成這些操作之前，OTP 會發送到用戶註冊的聯絡方式，必須輸入該代碼以完成交易。這確保即使有人存取了用戶的帳戶，沒有 OTP 也無法執行關鍵操作。 32 | 33 | 34 | -------------------------------------------------------------------------------- /src/content/terms/zh-Hant/resource-owner.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 資源擁有者 (Resource owner) 3 | tags: [oauth 2.0] 4 | description: 資源擁有者是有能力授予對受保護資源訪問權的身分（通常是用戶）。在 OAuth 2.0 中，資源擁有者可以授權客戶端代表其訪問資源伺服器上的資源。 5 | --- 6 | 7 | ## 什麼是資源擁有者 (Resource owner)？ 8 | 9 | 在 的上下文中，資源擁有者是有能力授予訪問受保護資源（例如數據、檔案或服務）權限的身分（通常是用戶）。 10 | 11 | 例如，你有一個名為 MyApp 的網絡應用程式，希望訪問用戶的 Google Drive。以下是一個典型的 OAuth 2.0 流程： 12 | 13 | ```mermaid 14 | sequenceDiagram 15 | participant 用戶 16 | participant MyApp 17 | participant 谷歌 18 | 19 | 用戶->>MyApp: 打開 MyApp 並
點擊 "連接 Google Drive" 20 | MyApp->>谷歌: 帶着授權請求重定向到谷歌 21 | 谷歌->>用戶: 登錄谷歌 22 | 用戶->>谷歌: 登錄 23 | 谷歌->>用戶: 請求訪問 Google Drive 的許可 24 | 用戶->>谷歌: 授予 MyApp 訪問權限 25 | 谷歌->>MyApp: 帶着授權數據（例如訪問令牌）重定向到 MyApp 26 | MyApp->>谷歌: 使用訪問令牌訪問用戶的 Google Drive 27 | ``` 28 | 29 | 在這個流程中，**用戶** 是授予 MyApp 訪問其 Google Drive 權限的 **資源擁有者 (Resource owner)**，而 **MyApp** 是想要訪問受保護資源的 ，而 **谷歌** 則是既作為 又作為 。 30 | 31 | 顧名思義，資源擁有者在 中擁有某些資源，並且可以在 的上下文中授權客戶端代表他們訪問這些資源。 32 | 33 | ## 為什麼資源擁有者重要？ 34 | 35 | 在 過程中，資源擁有者不可忽視，因為他們是明確授予或拒絕訪問其資源的人。資源擁有者的同意在技術和合規方面都是必須的： 36 | 37 | - **技術方面**：資源擁有者的同意確保了客戶端有必要的權限來訪問資源。與其提供一刀切的訪問，資源擁有者可以根據客戶端的請求授予部分訪問權限。另一方面，資源擁有者也可以隨時明確撤銷訪問。這種方法為 提供了一種清晰且可審計的方法。 38 | - **合規方面**：資源擁有者的同意在許多司法管轄區都是法律要求，特別是在處理敏感數據時。例如，《通用數據保護條例 (GDPR)》要求數據主體（資源擁有者）必須對數據處理活動提供明確的同意。 39 | 40 | ## 資源擁有者與資源伺服器 41 | 42 | 資源伺服器 負責托管和提供 **受保護的資源**。他們是驗證訪問令牌並將資源提供給客戶端的看門人。 43 | 44 | 另一方面，資源擁有者可以根據 策略對資源伺服器中的受保護資源進行完全或部分控制。 45 | 46 | 47 | 48 | -------------------------------------------------------------------------------- /src/content/terms/zh-Hant/role.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 角色 (Role) 3 | tags: [authorization] 4 | description: 角色 (Role) 是基於角色的存取控制 (RBAC) 系統中的核心概念，代表一組定義用戶可以執行哪些操作的權限，提供了一種有效的方式來管理和分配用戶的存取權限。 5 | --- 6 | 7 | ## 角色 (Role) 8 | 9 | 角色 (Role) 是 中的核心組件之一。它作為可以分配給用戶的權限的容器，充當用戶與其存取權限之間的中介。 10 | 11 | ```mermaid 12 | graph LR 13 | Users 14 | -->|assigned to| Roles 15 | -->|including| Permissions 16 | ``` 17 | 18 | 一個典型的角色 (Role) 結構包含一個名稱和一組權限： 19 | 20 | ```typescript 21 | const role = { 22 | name: 'order_admin', 23 | permissions: [ 24 | 'read:orders', // 查看訂單詳情 25 | 'write:orders', // 編輯訂單 26 | 'read:products' // 查看產品 27 | ] 28 | } 29 | ``` 30 | 31 | > [!Note] 32 | > 角色 (Role) 主要用於權限管理。對於存取控制的實施，建議直接檢查權限而不是角色 (Role)。詳情請參閱 。 33 | 34 | -------------------------------------------------------------------------------- /src/content/terms/zh-Hant/saml.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 安全斷言標記語言 (Security Assertion Markup Language, SAML) 3 | tags: [authentication, authorization] 4 | description: 安全斷言標記語言 (SAML) 是一種基於 XML 的標準，用於在身份提供者和服務提供者之間交換認證和授權數據。 5 | --- 6 | 7 | ## 什麼是 SAML？ 8 | 9 | SAML（通常稱為 SAML 2.0）是一種基於 XML 的標準，用於在兩方之間交換認證 (authentication) 和授權 (authorization) 數據： 和 。它被廣泛用於身份聯合和 解決方案。 10 | 11 | 如同名稱所示，SAML 傳遞關於使用者身份和屬性的斷言。這些斷言被數位簽名並可選擇加密以確保其完整性和機密性。 12 | 13 | ## SAML 如何運作？ 14 | 15 | 在深入了解 SAML 認證 (authentication) 流程之前，我們需要了解身份提供者和服務提供者如何識別和信任彼此。這種信任是通過元數據交換建立的，雙方分享以下信息： 16 | 17 | - **Entity ID**: 一個用於身份提供者或服務提供者的唯一標識符。 18 | - **Public key**: 用於驗證 SAML 斷言中的數位簽名。 19 | - **Endpoints**: 不同 SAML 操作的 URL，如認證請求和響應。 20 | 21 | 一旦建立了信任，SAML 認證 (authentication) 流程就可以進行： 22 | 23 | ```mermaid 24 | sequenceDiagram 25 | participant U as 使用者 26 | participant SP as 服務提供者 (SP) 27 | participant IdP as 身份提供者 (IdP) 28 | 29 | U->>SP: 嘗試訪問服務 30 | Note over SP: 使用者未認證 (authenticated) 31 | SP->>U: 重定向到 IdP 32 | 33 | U->>IdP: SAML 認證 (authentication) 請求 34 | Note over IdP: 驗證使用者身份 35 | 36 | IdP->>SP: 認證 (authentication) 成功 37 | IdP-->>SP: 發送 SAML 斷言 38 | 39 | Note over SP: 驗證 SAML 斷言 40 | SP->>SP: 處理斷言並提取使用者身份 41 | SP->>U: 已認證 (authenticated) 42 | ``` 43 | 44 | ### RelayState 45 | 46 | 在 SAML 流程中，`RelayState` 參數用於在認證 (authentication) 過程中維持使用者的狀態。它作為使用者在重定向到身份提供者前的原始請求的參考。服務提供者可以使用此參數在成功認證 (authentication) 後將使用者重定向回原始頁面或資源。 47 | 48 | RelayState 還用於防止 攻擊，通過確保使用者在認證 (authentication) 後被重定向回正確的頁面。 49 | 50 | ### SAML 斷言 51 | 52 | SAML 斷言是 SAML 協議的核心組件。它們包含有關使用者身份、屬性和認證 (authentication) 狀態的信息。有三種類型的 SAML 斷言： 53 | 54 | - **認證 (Authentication) 斷言**: 表示使用者已由身份提供者認證 (authenticated)。 55 | - **屬性斷言**: 包含關於使用者的其他信息，如角色、權限和個人資料數據。 56 | - **授權決策斷言**: 指定使用者對特定資源的訪問權。 57 | 58 | ## 採用 SAML 的考慮因素 59 | 60 | 自 2000 年代初SAML 被廣泛採用於企業環境中。在為你的應用程序採用 SAML 時，這裡有一些關鍵考慮因素： 61 | 62 | - 複雜性：與現代框架如 和 相比，SAML 集成可能會較為複雜。 63 | - 傳輸效率：由於 XML 格式，SAML 消息可能較大，這可能影響網絡性能。 64 | - 安全性：SAML 斷言必須防止篡改和竊聽。確保你的 SAML 實現遵循最佳加密和數位簽名做法。 65 | 66 | 儘管有這些考慮因素，SAML 仍然是一個強大且被廣泛使用的標準，用於企業環境中的安全身份聯合和單一登入解決方案。然而，對於新的應用程序或服務，你可能想考慮像 OAuth 2.0 和 OpenID Connect 這樣的現代替代方案，以獲得更輕量級和開發者友好的認證 (authentication) 和授權 (authorization) 方法。 67 | 68 | 69 | 70 | 77 | -------------------------------------------------------------------------------- /src/content/terms/zh-Hant/scope.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 範圍 (Scope) 3 | tags: [authorization] 4 | description: 範圍 (Scope) 定義應用程式向使用者請求訪問其受保護資源的許可權。它是 OAuth 2.0 和 OIDC 中控制應用程式可訪問使用者資料的級別的基本概念。 5 | --- 6 | 7 | ## 什麼是範圍 (Scope)？ 8 | 9 | 在 和 協議中，**範圍 (Scope)** 是一種限制應用程式對使用者資源訪問的機制。它定義了應用程式向使用者請求的權限。 10 | 11 | 範圍 (Scopes) 由授權 (authorization) 伺服器定義為字串表示。當應用程式請求訪問使用者資源時，它在授權 (authorization) 請求中指定所需的範圍 (scopes)。然後使用者會在授權過程中被要求授予或拒絕這些權限。 12 | 13 | ### 為什麼使用範圍 (scopes)？ 14 | 15 | - **細緻的訪問控制 (access control)**：範圍 (Scopes) 允許應用程式僅請求執行特定操作所需的權限，從而減少未授權訪問的風險。 16 | - **使用者同意**：範圍 (Scopes) 幫助使用者瞭解應用程式將訪問的資料及其原因。 17 | - **安全性**：範圍 (Scopes) 有助於防止應用程式超出其訪問權限，增強使用者資料的安全性。 18 | 19 | ## 範圍 (Scope) 如何運作？ 20 | 21 | 當應用程式啟動 OAuth 2.0 / OIDC 授權 (authorization) 過程時，它會在授權 (authorization) 請求中包含一系列範圍 (scopes)。授權 (authorization) 伺服器隨後向使用者顯示列出請求範圍 (scopes) 的同意畫面。使用者可以選擇授予或拒絕對每個範圍 (scope) 的訪問。此過程通常在應用程式是需要訪問使用者資源的第三方應用程式時使用。 22 | 23 | 或者，如果應用程式被授權 (authorization) 伺服器信任，則可能不會提示使用者進行同意，而是自動同意並授予所有請求的範圍 (scopes)。 24 | 25 | ## 定義範圍 (Scopes) 26 | 27 | 範圍 (Scopes) 通常由 API 提供者定義。它們可以是： 28 | - **標準範圍 (Standard scopes)**：由 OAuth 2.0 規範定義的常用範圍 (scopes)，可由不同應用程式和服務共享。例如 `openid`、`profile`、`email`。 29 | - **自定義範圍 (Custom scopes)**：特定於某個應用程式或服務，針對其獨特需求量身定制。例如 `read:orders`、`write:comments`。 30 | 31 | ## 範圍 (Scopes) 在 OIDC 和身份管理中的應用 32 | 33 | 範圍 (Scopes) 可用於 OIDC 的各個方面，包括但不限於： 34 | 35 | - **認證 (Authentication)**：範圍 (Scopes) 可用於在認證 (authentication) 過程中請求特定的使用者資訊。例如 `profile`、`email`。 36 | - **授權 (Authorization)**：範圍 (Scopes) 可用於請求對特定資源的訪問或執行特定操作。例如 `read:orders`、`write:comments`。 37 | - **同意**：在同意畫面上，範圍 (Scopes) 會呈現給使用者，以告知應用程式請求的權限。 38 | - **令牌 (Token) 發行**：範圍 (Scopes) 會包含在令牌 (token) 響應中，以指示授予應用程式的權限。 39 | - **令牌 (Token) 驗證**：範圍 (Scopes) 可用於當應用程式持有令牌 (token) 訪問受保護資源時，驗證其訪問權限。 40 | - **資源伺服器 (Resource server)**：範圍 (Scopes) 可由資源伺服器用於根據授予應用程式的權限強制執行訪問控制 (access control) 策略。 41 | - **使用者資料**：範圍 (Scopes) 可用於請求超出基本認領 (claims) 的其他使用者資料資訊。 42 | 43 | ## 最佳實踐 44 | 45 | - **請求最少的範圍 (scopes)**：始終請求應用程式運行所需的最少範圍 (scopes) 集，這可最大程度地減少過度許可的風險並增強使用者信任。 46 | - **說明範圍 (scope) 使用情況**：向使用者清楚說明每個範圍 (scope) 的必要性。透明度有助於獲得使用者同意。 47 | - **盡可能使用標準範圍 (scopes)**：利用標準範圍 (scopes) 以確保兼容性並降低複雜性。 48 | 49 | 50 | 51 | -------------------------------------------------------------------------------- /src/content/terms/zh-Hant/service-provider.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 服務提供者 (Service provider, SP) 3 | tags: [authentication, authorization] 4 | description: 服務提供者 (Service provider, SP) 是依賴身份提供者 (Identity provider, IdP) 進行認證 (Authentication) 和授權的應用程序或服務。 5 | --- 6 | 7 | ## 什麼是服務提供者 (Service provider, SP)？ 8 | 9 | 在 的領域中，服務提供者 (SP)（或者在 的上下文中稱為**信賴方**）是一個依賴 進行認證 (Authentication) 和授權的應用程序或服務。它負責向用戶提供服務，並根據身份提供者發布的令牌執行 策略。 10 | 11 | ```mermaid 12 | graph LR 13 | IdP[身份提供者] 14 | SP["服務提供者
(應用程序、服務、API)"] 15 | IdP -->|認證用戶| SP 16 | IdP -->|發布令牌| SP 17 | IdP -->|提供用戶資訊| SP 18 | ``` 19 | 20 | ## 服務提供者標準 21 | 22 | 對於服務提供者來說，沒有嚴格的標準，因為它們可以是任何需要身份管理的應用程序或服務。然而，服務提供者通常遵循其所依賴的身份提供者設置的標準。例如，如果身份提供者支持 ，則服務提供者通常會使用 OIDC 進行認證 (Authentication) 和授權。 23 | 24 | ## 服務提供者架構 25 | 26 | "服務提供者"這個術語並不特指某種架構或實現。通常，服務提供者需要向身份提供者註冊以建立信任並啟用安全通信。註冊過程通常涉及交換元數據和客戶端憑證。 27 | 28 | 例如，在 OpenID Connect 的上下文中，服務提供者的元數據通常包括： 29 | 30 | - **Client ID**：服務提供者的唯一標識符。 31 | - **Client secret**：用來認證 (Authentication) 服務提供者的共享密鑰。 32 | - **重定向 URI**：身份提供者在認證 (Authentication) 和授權後將用戶重定向回的 URI。 33 | 34 | 一旦註冊，服務提供者可以通過將用戶重定向到身份提供者的指定端點來啟動認證 (Authentication) 過程。 35 | 36 | 當服務提供者是為非交互性使用情境構建時，它們通常被稱為需要 通訊的 客戶端。 37 | 38 | 39 | 40 | 47 | -------------------------------------------------------------------------------- /src/content/terms/zh-Hant/token-introspection.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 權杖內省 (Token introspection) 3 | tags: [oauth 2.0, oidc] 4 | description: 權杖內省 (Token introspection) 是 OAuth 2.0 的擴展，允許客戶端 (clients) 查詢授權伺服器 (authorization server) 以驗證訪問權杖 (access tokens) 並獲取其元數據。 5 | --- 6 | 7 | ## 什麼是權杖內省 (Token introspection)？ 8 | 9 | 權杖內省 (Token introspection) 是在 [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662) 中定義的 OAuth 2.0 擴展，允許 客戶端 (clients) 查詢 以驗證訪問權杖 (access tokens) 並獲取其元數據。當發生以下情況時，此擴展特別有用： 10 | 11 | - 客戶端想要實時驗證訪問權杖 (access token) 的有效性。 12 | - 訪問權杖 (access token) 是 不透明的 (opaque)（不是自包含的）並且需要授權伺服器 (authorization server) 來驗證。 13 | 14 | ## 權杖內省 (Token introspection) 如何運作？ 15 | 16 | 以下是一個權杖內省 (token introspection) 請求的非常規範示例： 17 | 18 | ```http 19 | POST /introspect HTTP/1.1 20 | Host: authorization-server.example.com 21 | Content-Type: application/x-www-form-urlencoded 22 | 23 | token=random-token-value 24 | &token_type_hint=access_token 25 | ``` 26 | 27 | `token_type_hint` 參數是可選的，應設置為正在內省的權杖類型。如果訪問權杖 (access token) 有效，授權伺服器 (authorization server) 將會響應權杖的元數據： 28 | 29 | ```http 30 | HTTP/1.1 200 OK 31 | Content-Type: application/json 32 | 33 | { 34 | "active": true, 35 | "scope": "read write", 36 | "client_id": "client-id", 37 | "username": "johndoe", 38 | "token_type": "Bearer", 39 | "exp": 1634020800, 40 | "iat": 1634017200 41 | } 42 | ``` 43 | 44 | 值得注意的是，並非所有授權伺服器 (authorization servers) 都支持權杖內省 (token introspection)，且並非所有權杖都是可內省的。 可能會根據各種因素限制權杖內省 (token introspection) 的使用，例如，某些授權伺服器 (authorization servers) 可能不支持對 JWTs 的內省。 45 | 46 | ### 權杖內省 (Token introspection) 請求中的關鍵參數 47 | 48 | 以下是權杖內省 (token introspection) 請求中的兩個關鍵參數： 49 | 50 | - **`token`**: 要內省的權杖。 51 | - **`token_type_hint`**: 正在內省的權杖類型。可以是 `access_token` 或 `refresh_token`。 52 | 53 | 54 | 55 | -------------------------------------------------------------------------------- /src/content/terms/zh-Hant/totp.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 基於時間的一次性密碼 (Token-based one-time password, TOTP) 3 | tags: [authentication] 4 | description: 基於時間的一次性密碼 (TOTP) 是一個臨時的、唯一的代碼，由使用當前時間作為關鍵因素的算法生成。 5 | --- 6 | 7 | ## 什麼是 TOTP？ 8 | 9 | 基於時間的一次性密碼 (TOTP) 是一個臨時的、唯一的代碼，由使用當前時間作為關鍵因素的算法生成。類似於通用的 ，TOTP 只使用一次，但它有固定的壽命，通常範圍為 30 至 60 秒。過期後，將自動生成一個新代碼。 10 | 11 | TOTP 標準由互聯網工程任務組 (IETF) 根據 [RFC 6238](https://datatracker.ietf.org/doc/html/rfc6238) 定義，並廣泛應用於各種雙因素認證 (2FA) 和多因素認證 (MFA) 系統中。由於 TOTP 依賴於客戶端（用戶設備）和服務器之間的同步時間，它們提供了高水平的安全性並且難以預測或重用。 12 | 13 | ## TOTP 的運作原理 14 | 15 | TOTP 的生成涉及以下步驟： 16 | 17 | 1. 共享密鑰：在初始設置過程中，生成並安全地存儲在客戶端和服務器上的共享密鑰。此密鑰通常編碼為用戶使用認證應用程序掃描的二維碼。 18 | 2. 時間間隔：將當前時間分為固定間隔，通常為 30 秒。 19 | 3. 算法應用：將共享密鑰和當前時間戳輸入到基於哈希的算法中（通常是 HMAC-SHA1）以生成唯一的數字代碼。 20 | 4. 同步：客戶端和服務器均使用相同的共享密鑰和當前時間戳獨立生成代碼。只有當兩者同步時，代碼才匹配。 21 | 5. 驗證：當用戶登錄或執行關鍵交易時，他們輸入在其認證應用程序上顯示的 TOTP。然後服務器將其與其內部生成的 TOTP 進行比較，以進行驗證。 22 | 23 | ## 何時使用 TOTP 24 | 25 | 在大多數情況下，推薦使用普通 OTP，但在無法“觸發”新密碼的情況下，推薦使用 TOTP。 26 | 27 | - TOTP 示例：Authenticator App 28 | - OTP 示例：電子郵件、SMS 29 | 30 | ## OTP 和 TOTP 之間的區別是什麼？ 31 | 32 | 主要區別在於 TOTP 是基於時間的，因此適合於設備未連接到服務器的情況。服務器可以輕鬆地將新密碼發送到電子郵件地址或電話號碼，但這需要電子郵件或電話在線。然而，Authenticator App 可以保持離線並使用“時間”來驗證密碼。 33 | 34 | 35 | -------------------------------------------------------------------------------- /src/content/terms/zh-Hant/userinfo-endpoint.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Userinfo 端點 (Userinfo endpoint) 3 | tags: [oidc] 4 | description: Userinfo 端點 (Userinfo endpoint) 是一個 OpenID Connect (OIDC) 端點，提供使用者資訊給客戶端。它是 ID token 的補充端點，允許客戶端檢索額外的使用者資訊。 5 | --- 6 | 7 | ## 什麼是 userinfo 端點 (Userinfo endpoint)？ 8 | 9 | 在 中，userinfo 端點 (Userinfo endpoint) 是 的一個端點，提供使用者資訊給 客戶端。userinfo 端點通常是 的補充端點，允許客戶端檢索不包括在 ID token 中的額外使用者資訊。 10 | 11 | userinfo 端點在 [OpenID Connect 核心規範](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) 中定義，通常在客戶端取得 ID token 之後由客戶端存取。 12 | 13 | ## userinfo 端點如何運作？ 14 | 15 | 當客戶端向 userinfo 端點發出請求時，需要包含從 獲得的 access token，並使用 `GET` 或 `POST` HTTP 方法。userinfo 端點會驗證 access token，並在回應中返回使用者資訊。 16 | 17 | 以下是一個非規範的 userinfo 請求範例： 18 | 19 | ```http 20 | GET /userinfo HTTP/1.1 21 | Host: openid-provider.example.com 22 | Authorization: Bearer some-access-token 23 | ``` 24 | 25 | 不同 OpenID Providers 的 userinfo 端點路徑可能會有所不同。你可以參考提供者的 找到 userinfo 端點的 URL。如果 access token 有效，userinfo 端點會用使用者資訊回應： 26 | 27 | ```http 28 | HTTP/1.1 200 OK 29 | Content-Type: application/json 30 | 31 | { 32 | "sub": "user123", 33 | "name": "Alice", 34 | "email": "alice@foo.com", 35 | "birthdate": "1990-01-01", 36 | "address": { 37 | "street": "1234 Elm St", 38 | "city": "Springfield", 39 | "country": "US" 40 | } 41 | } 42 | ``` 43 | 44 | 回應可能包含各種使用者屬性，比如 `name`、`email`、`birthdate` 和 `address`；通常，它包含比 更多的 宣告 (claims)。實際返回的屬性取決於 配置和使用者的同意。請查閱你的 OpenID Provider 的文件以獲取可用的具體屬性。 45 | 46 | ### 簽名和加密 47 | 48 | userinfo 回應可以被簽名和/或加密以確保其完整性和機密性。若應用了其中一種或兩種保護，userinfo 端點回應將是一個 而非普通的 JSON 物件。 49 | 50 | 51 | -------------------------------------------------------------------------------- /src/content/terms/zh/auth.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: Auth (释义) 3 | tags: [authentication, authorization] 4 | description: 术语“auth”通常是 authentication 或 authorization 的缩写。这些概念相关但本质不同。 5 | --- 6 | 7 | ## Auth 8 | 9 | 本页面是术语“auth”的释义。它通常用作以下的缩写： 10 | 11 | - ：验证身份所有权（例如，用户或服务）的过程。它回答的问题是“你拥有什么身份？” 12 | - ：确定身份可以对资源执行哪些操作的过程。它回答的问题是“你能做什么？” 13 | 14 | > [!Note] 15 | > 有时，authentication 和 authorization 被分别称为“AuthN”和“AuthZ”。 16 | 17 | 这两个概念在 领域中都很重要，但它们本质上是不同的。让我们看一个例子：一个名为 MyStorage 的 Web 应用具有上传文件和连接到 Google Drive 的功能。一个典型的用户流程是： 18 | 19 | ```mermaid 20 | sequenceDiagram 21 | participant User 22 | participant MyStorage 23 | participant Google 24 | autonumber 25 | 26 | User->>MyStorage: 登录 MyStorage 27 | MyStorage->>User: 欢迎, User！ 28 | User->>MyStorage: 点击“连接 Google Drive” 29 | MyStorage->>Google: 跳转到 Google
带有授权请求 30 | Google->>User: 提示用户登录 31 | User->>Google: 登录 Google 32 | Google->>User: 请求访问 Google Drive 的权限 33 | User->>Google: 授予 MyStorage 访问权限 34 | Google->>MyStorage: 跳转到 MyStorage
带有授权数据（例如，access token） 35 | MyStorage->>Google: 使用 access token 访问用户的 Google Drive 36 | ``` 37 | 38 | 在这个流程中，用户执行了两个 authentication 步骤：一个是与 MyStorage（步骤 1），另一个是与 Google（步骤 6）；以及一个 authorization 步骤：授予访问 Google Drive 的权限（步骤 8）。 39 | 40 | ## 你指的是哪个？ 41 | 42 | 当你看到“auth”这个术语时，重要的是要明确它指的是 authentication 还是 authorization；否则，你可能期望涵盖这两个过程（就像这个网站一样）。 43 | 44 | 45 | -------------------------------------------------------------------------------- /src/content/terms/zh/authorization.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 授权 (Authorization) 3 | tags: [authorization] 4 | description: 授权 (Authorization) 是确定一个身份对资源可以执行哪些操作的过程。它是定义和强制执行访问策略的基本安全机制。 5 | --- 6 | 7 | ## 什么是授权 (Authorization)？ 8 | 9 | > **简而言之**：授权 (Authorization) 回答了“你能做什么？”这个问题。 10 | 11 | 授权 (Authorization) 是一个决策过程，用于确定一个身份（用户、服务或设备）是否具有对某个资源执行特定操作的必要权限。让我们看看一些例子： 12 | 13 | - 在一个在线文档编辑器中，用户可以与其他人共享文档。 14 | - 在云存储服务中，服务可以在特定文件夹中读取和写入文件。 15 | - 在智能家居系统中，设备可以打开客厅的灯。 16 | 17 | 所有这些例子都涉及身份（主体）对资源执行操作。当然，授权 (Authorization) 也可能失败，例如，当用户尝试删除他们没有权限访问的文件时。 18 | 19 | 授权 (Authorization) 的基本模型很简单：如果 **身份** 对 **资源** 执行 **操作**，那么 **接受** 或 **拒绝**。 20 | 21 | ### 认证 (Authentication) 和授权 (Authorization) 的区别 22 | 23 | 认证 (Authentication) 和授权 (Authorization) 经常被混淆，但它们有根本的不同： 回答了“你拥有什么身份？”这个问题。此外，在大多数情况下，授权 (Authorization) 发生在认证 (Authentication) 之后，因为系统需要在做出访问决策之前知道身份。 24 | 25 | ### 授权 (Authorization) 和访问控制 (Access Control) 的区别 26 | 27 | 授权 (Authorization) 是访问控制 (Access Control) 的一个子集。访问控制是一个更广泛的概念，包括授权 (Authorization) 和其他对访问管理的限制。换句话说，访问控制是描述对资源访问进行选择性限制的总称，而授权 (Authorization) 专门指决策过程。 28 | 29 | ## 授权 (Authorization) 的工作原理 30 | 31 | 授权 (Authorization) 通常使用 实现。它们定义了权限如何在系统中被分配和执行。 32 | 33 | ## 授权 (Authorization) 框架（协议） 34 | 35 | 虽然 是一个非常流行的授权 (Authorization) 框架，但值得注意的是，OAuth 2.0 并没有定义使用哪个访问控制模型。相反，它专注于授权 (Authorization) 的委托和访问令牌 (Access Tokens) 的颁发。 36 | 37 | 也就是说，OAuth 2.0 适合于用户授予客户端访问其资源权限的第三方授权 (Authorization) 场景。例如，当你使用 Google 帐户登录网站时，你是在授权 (Authorization) 网站访问你的 Google 个人资料。 38 | 39 | 如果你处理的是第一方授权 (Authorization) （例如，在你的应用程序或组织内），你可能需要实现一个访问控制模型，比如 或 。结合 和访问控制模型可以为认证 (Authentication) 和授权 (Authorization) 提供坚实的基础。 40 | 41 | 建议使用提供认证 (Authentication) 和授权 (Authorization) 功能的 ，而不是自行构建授权 (Authorization) 系统。一个好的身份提供者将处理访问控制的复杂性，并为你的应用程序提供一个安全且可扩展的解决方案。 42 | 43 | 44 | 45 | -------------------------------------------------------------------------------- /src/content/terms/zh/claim.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 声明 (Claim) 3 | tags: [oauth 2.0, oidc] 4 | description: 在 JSON Web Token (JWT) 中，声明 (Claim) 是一个传递特定信息的键值对。在更广泛的上下文中，声明可以是表示信息的任何键值对。 5 | --- 6 | 7 | ## 什么是声明 (Claim)？ 8 | 9 | 声明 (Claim) 是一个传递特定信息的键值对。例如，在一个 JSON 对象中： 10 | 11 | ```json 12 | { 13 | "sub": "foo", 14 | "email": "foo@bar.com" 15 | } 16 | ``` 17 | 18 | 在这个例子中，`sub` 是一个声明，表示主题标识符，其值为 `foo`；`email` 是一个声明，表示电子邮件地址，其值为 `foo@bar.com`。 19 | 20 | > 我们使用 *subject* 而不是 *user*，因为在没有明确定义的情况下，主题 (`sub`) 可以表示一个用户、设备或任何实体。 21 | 22 | ### 声明的用途 23 | 24 | 声明在各种上下文中被广泛使用，例如： 25 | 26 | - : 在 JWT 中，声明用于表示有关令牌的信息，例如签发者 (`iss`)、主题 (`sub`) 和过期时间 (`exp`)。 27 | - : 在 OIDC 中，声明用于在 和 中表示用户信息，例如用户的电子邮件地址 (`email`)、姓名 (`name`) 和个人资料图片 (`picture`)。 28 | 29 | ### 标准声明 30 | 31 | 在 JWT 和 OIDC 中，有一些规范定义的标准声明。一些常见的标准声明包括： 32 | 33 | - **`iss`**: 令牌的签发者。例如，如果颁发令牌的 是 `https://example.com`，在大多数情况下，`iss` 声明将是相同的 (`https://example.com`)。 34 | - **`sub`**: 令牌的主题。它代表令牌所涉及的实体。例如，在一个 ID 令牌中，`sub` 声明通常代表用户标识符。 35 | - **`aud`**: 令牌的受众。它表示令牌的目标接收者。例如，如果令牌用于访问 `https://api.example.com` 的 API，`aud` 声明将是相同的 (`https://api.example.com`)。 36 | - **`exp`**: 令牌的到期时间。它指示令牌何时不再被接受处理。 37 | - **`nbf`**: 令牌的“不可用之前”时间。它指示令牌何时开始被接受处理。 38 | - **`iat`**: 令牌的签发时间。它指示令牌何时被签发。 39 | - **`jti`**: 令牌的 JWT ID。它为令牌提供了一个唯一标识符。 40 | 41 | OIDC 还定义了用于用户信息的其他标准声明。有关详细信息，请参阅 OIDC 规范中的 [Claims](https://openid.net/specs/openid-connect-core-1_0.html#Claims)。 42 | 43 | ### 自定义声明 44 | 45 | 除了标准声明外，你可以定义自定义声明来表示特定于应用程序的信息。例如，你可以包含一个 `role` 声明来表示用户在应用程序中的角色。 46 | 47 | 自定义声明可以使用[统一资源标识符 (URI)](https://blog.logto.io/unveiling-uri-url-and-urn)进行命名空间处理，以避免与其他声明冲突。例如： 48 | 49 | ```json 50 | { 51 | "https://example.com/claims/role": "admin" 52 | } 53 | ``` 54 | 55 | 在这个例子中，`role` 声明使用 `https://example.com/claims/` 进行命名空间处理以确保唯一性。或者，你可以为自定义声明定义你自己的[统一资源名 (URN)](https://blog.logto.io/unveiling-uri-url-and-urn)： 56 | 57 | ```json 58 | { 59 | "urn:example:claims:role": "admin" 60 | } 61 | ``` 62 | 63 | 在这个例子中，`role` 声明使用 `urn:example:claims:` 进行命名空间处理。 64 | 65 | 66 | 67 | -------------------------------------------------------------------------------- /src/content/terms/zh/identity-provider.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 身份提供者 (Identity provider, IdP) 3 | tags: [authentication, authorization] 4 | description: 身份提供者 (IdP) 是一个管理身份的服务。现代身份提供者支持 OpenID Connect (OIDC) 进行认证 (Authentication) 和 OAuth 2.0 进行授权 (Authorization)。 5 | --- 6 | 7 | ## 什么是身份提供者 (IdP)？ 8 | 9 | 在 领域，身份提供者 (IdP) 是管理身份的中央服务。它负责认证 (Authentication) 用户、签发身份令牌，并向 服务提供者（例如应用程序、服务、API）提供用户信息。 10 | 11 | ```mermaid 12 | graph LR 13 | IdP[身份提供者] 14 | SP["服务提供者
(应用程序，服务，API)"] 15 | IdP -->|认证用户| SP 16 | IdP -->|签发令牌| SP 17 | IdP -->|提供用户信息| SP 18 | ``` 19 | 20 | 除了 ，现代身份提供者还负责 （执行 策略）并支持高级功能，如 和 。 21 | 22 | ## 身份提供者标准 23 | 24 | 由于身份管理的性质以及互操作性的需求，没有标准来构建身份提供者将是不切实际的且效率低下。以下是一些典型场景： 25 | 26 | - 两个身份提供者需要相互通信以交换用户信息（例如，社交登录）。 27 | - 一个应用程序需要使用多个身份提供者来认证 (Authentication) 用户（例如，联合身份）。 28 | - 一个身份提供者需要支持多种类型的客户端（例如，Web、移动、物联网）。 29 | 30 | 为了应对这些场景，业界为身份提供者开发了几种流行的标准： 31 | 32 | - ：一种广泛使用的授权 (Authorization) 框架，使应用程序能够代表用户或服务获取访问权限。 33 | - ：一个基于 OAuth 2.0 之上的身份层，提供认证 (Authentication) 和用户信息。 34 | - ：一种在安全域之间交换认证 (Authentication) 和授权 (Authorization) 数据的标准。 35 | 36 | 对于新应用程序，OpenID Connect (OIDC) 是构建身份提供者或集成现有身份提供者的推荐标准。 37 | 38 | ## 身份提供者架构 39 | 40 | 术语“身份提供者”并不指定特定的架构或实现。这就是说，身份提供者可以是单体应用程序、微服务或云服务。 41 | 42 | ```mermaid 43 | graph LR 44 | subgraph 单体服务 45 | IdP[身份提供者] 46 | Module1 47 | Module2 48 | end 49 | ``` 50 | 51 | 由于身份管理的复杂性和重要性，现代应用程序倾向于使用作为独立服务或供应商解决方案的专业身份提供者。 52 | 53 | ```mermaid 54 | graph LR 55 | IdP[身份提供者] <--> SP1[服务提供者 1] 56 | IdP <--> SP2[服务提供者 2] 57 | ``` 58 | 59 | ## 身份提供者功能 60 | 61 | 现代身份提供者提供广泛的功能以支持各种使用场景和需求。以下是一些常见功能： 62 | 63 | - ：使用多种方法验证用户身份（例如，用户名/密码，社交登录，）。 64 | - ：执行访问控制策略并管理用户权限（例如，，）。 65 | - **用户管理**：创建、更新和删除用户账户和配置文件；向 服务提供者 提供用户数据。 66 | - **令牌管理**：签发和管理身份令牌（例如，ID 令牌，访问令牌，刷新令牌）。 67 | - ：允许用户一次认证 (Authentication) 后访问多个应用程序。 68 | - ：支持多组织或租户，具有隔离的用户数据和配置。 69 | 70 | 71 | 72 | 79 | -------------------------------------------------------------------------------- /src/content/terms/zh/jwe.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: JSON Web 加密 (JSON Web Encryption, JWE) 3 | tags: [oidc, jose] 4 | description: JSON Web 加密 (JWE) 是一种以 JSON 格式加密和解密数据的标准方式。它通常用于保护传输 JSON Web 令牌 (JWTs) 中的敏感信息。 5 | --- 6 | 7 | ## 什么是 JSON Web 加密 (JWE)？ 8 | 9 | 如 RFC 7516 中定义，JSON Web 加密 (JWE) 是一种以 JSON 格式加密和解密数据的机制。它为数据添加了一层保密性，在通过不受信任的网络传输敏感信息时特别有用。 10 | 11 | JWE 通常与 JSON Web 令牌 (JWTs) 结合使用以保护有效载荷数据。例如，一个 或 可以使用 JWE 加密，以确保数据在传输过程中的安全。 12 | 13 | ## JWE 如何工作？ 14 | 15 | JWE 有两种序列化格式：紧凑和 JSON。每种格式都有其表示加密数据的方式。 16 | 17 | ### 紧凑序列化 18 | 19 | 在紧凑序列化中，JWE 被表示为一个包含五个 Base64URL 编码部分的字符串，这些部分之间用点（`.`）分隔。这五个部分是： 20 | 21 | ``` 22 | {{header}}.{{encrypted-key}}.{{iv}}.{{ciphertext}}.{{tag}} 23 | ``` 24 | 25 | 每个部分的用途如下： 26 | 27 | - `header`：包含有关加密算法和密钥管理的元数据。 28 | - `encrypted-key`：用于加密有效载荷的加密内容加密密钥 (CEK)。 29 | - `iv`：加密过程中使用的初始化向量。 30 | - `ciphertext`：加密的有效载荷数据。 31 | - `tag`：用于验证加密数据完整性的认证标签。 32 | 33 | ### JSON 序列化 34 | 35 | JSON 序列化更为详细，并提供了一种结构化的方式来表示 JWE。JWE 表示为一个包含以下属性的 JSON 对象： 36 | 37 | ```json 38 | { 39 | "protected": "{{protected-header}}", 40 | "unprotected": "{{unprotected-header}}", 41 | "header": "{{header}}", 42 | "encrypted_key": "{{encrypted-key}}", 43 | "iv": "{{iv}}", 44 | "ciphertext": "{{ciphertext}}", 45 | "tag": "{{tag}}", 46 | "aad": "{{additional-authenticated-data}}" 47 | } 48 | ``` 49 | 50 | - `protected`：包含 Base64URL 编码的受保护头。 51 | - `unprotected`：包含 JWE 共享未受保护头。 52 | - `header`：包含 JWE 每个接收者的未受保护头。 53 | - `encrypted_key`：包含 Base64URL 编码的加密内容加密密钥 (CEK)。 54 | - `iv`：包含 Base64URL 编码的初始化向量。 55 | - `ciphertext`：包含 Base64URL 编码的密文（加密的有效载荷）。 56 | - `tag`：包含 Base64URL 编码的认证标签。 57 | - `aad`：包含 Base64URL 编码的附加认证数据。 58 | 59 | --- 60 | 61 | 客户端应该能够使用适当的密钥和算法解密 JWE。可以使用预先通信的密钥或从密钥协商协议派生的密钥解密 JWE。 62 | 63 | 例如，一个 可以使用 JWE 加密，客户端可以使用从 OpenID 提供者的 `jwks_uri` 端点获得的适当密钥解密它。 64 | 65 | 66 | 67 | 74 | -------------------------------------------------------------------------------- /src/content/terms/zh/management-api.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 管理 API (Management API) 3 | tags: [api, integration] 4 | description: 在身份和访问管理 (IAM) 的背景下，管理 API 允许对用户、应用程序、角色和权限等资源进行编程管理。通常是 RESTful，它在 IAM 系统和用户界面之间提供了一个抽象层，支持自动化、集成和自定义功能开发。 5 | --- 6 | 7 | ## 什么是管理 API？ 8 | 9 | 管理 API 的定义可能因所使用的软件或服务而异。在身份和访问管理 (IAM) 的背景下，管理 API 通常指一组允许你以编程方式管理 IAM 相关资源的 APIs。例如，用户、应用程序、角色、权限、组织等。 10 | 11 | 虽然名字没有具体指明实现方式，但鉴于其明确定义资源和可以对其执行的操作的特性，管理 API 通常是 RESTful 的。这就是说，当你看到 `POST /users` 时，可以预期这个 API 调用将创建一个新用户。 12 | 13 | ## 为什么管理 API 很重要？ 14 | 15 | 管理 API 在 IAM 系统之上但在用户界面之下创建了一个独立的抽象层。这使得开发人员可以自动化地管理 IAM 资源，这在以下几种情况下尤其有用： 16 | 17 | ### 1. 自动化 18 | 19 | 如其名所示，管理 API 允许你使用代码来管理资源，而不是通过用户界面手动点击。这在需要管理大量用户、应用程序或角色时尤其有用。例如，你可以编写一个脚本从 CSV 文件导入用户，并将其分配到正确的角色和权限。 20 | 21 | ### 2. 集成 22 | 23 | 管理 API 为服务对服务的通信或机器对机器的通信创建了一种标准方式。当你有多个服务需要与 IAM 系统通信时，与其为每个服务实施自定义集成，不如使用设计良好的管理 API 通过组合 API 调用来支持所有服务。例如，一个需要列出特定角色下所有用户的服务可以通过调用 `GET /roles/{role_id}/users` 来实现。 24 | 25 | ### 3. 组合和功能扩展 26 | 27 | 由于各种业务需求，IAM 系统可能无法提供所有确切的功能，特别是在涉及复杂访问控制 (access control) 要求时。管理 API 允许你在现有 IAM 系统的基础上构建自定义功能，而无需修改底层平台或架构。 28 | 29 | 让我们看一个日常示例：最终用户需要更改其电子邮件地址。不同的应用程序可能有不同的要求： 30 | 31 | 1. 应用程序 A 要求用户验证旧的和新的电子邮件地址。 32 | 2. 应用程序 B 要求用户在更改电子邮件地址前验证现有密码。 33 | 3. 应用程序 C 要求用户验证现有密码，并由管理员批准电子邮件更改。 34 | 35 | 使用管理 API，你可以构建一个自定义服务，通过按正确的顺序调用必要的 API 来协调这些要求。你甚至可以将管理 API 与你的服务的 API 结合以实现复杂的工作流。以应用程序 C 为例： 36 | 37 | 1. 用户在应用程序 C 中点击“更改电子邮件”，这向你的服务发送请求 `POST /email-change-requests`。它创建了一个新的电子邮件更改请求并返回标识符 `foo`。 38 | 2. 应用程序 C 向用户显示一个对话框，要求他们输入现有密码。 39 | 3. 用户输入密码，应用程序 C 将请求 `PATCH /email-change-requests/foo` 发送给你的服务，附带密码。在后台，你的服务通过调用管理 API `POST /users/{user_id}/verify-password` 验证密码。 40 | 4. 如果密码正确，你的服务将在电子邮件更改请求 `foo` 中创建一个成功验证记录。 41 | 5. 在管理面板中，管理员可以使用 `GET /email-change-requests?status=pending` 查看待处理的电子邮件更改请求。 42 | 6. 如果管理员批准请求，管理面板将请求 `PATCH /email-change-requests/foo` 发送给你的服务，附带管理员的批准。 43 | 7. 然后你的服务将调用管理 API `PATCH /users/{user_id}` 来更新用户的电子邮件地址。如果无法更新电子邮件地址，管理 API 将返回错误，你的服务可以相应地进行处理。 44 | 45 | 注意在上述示例中，我们的最终用户从未直接与管理 API 交互。他们与应用程序 C 交互，后者在后台协调管理 API 调用以实现所需的工作流。 46 | 47 | ## 优秀的管理 API 应该是什么样的？ 48 | 49 | - **RESTful**：遵循 RESTful 原则，使 API 易于预测和使用。 50 | - **资源导向**：将资源表示为名词，并使用 HTTP 方法对其执行操作。 51 | - **一致性**：使用一致的命名约定、错误处理和响应格式。 52 | - **安全性**：实施正确的认证 (Authentication) 和授权 (Authorization) 机制来保护 API。 53 | - **文档化**：提供清晰简洁的文档，说明如何使用 API，包括示例和用例。 54 | - **兼容性**：在引入新版本的 API 时确保向后兼容。 55 | - **全面性**：涵盖所有必要的操作，以有效管理 IAM 资源。 56 | 57 | 还有其他方面，如性能和扩展性，它们更多地与基础设施相关，而不是 API 设计本身。然而，在实践中，一个好的管理 API 应该也考虑这些方面。 58 | 59 | 66 | -------------------------------------------------------------------------------- /src/content/terms/zh/otp.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 一次性密码 (One-time password, OTP) 3 | tags: [authentication] 4 | description: 一次性密码 (OTP) 是用于单个交易或会话的唯一、临时代码。 5 | --- 6 | 7 | ## 什么是 OTP？ 8 | 9 | 一次性密码 (OTP) 是用于单个交易或会话的唯一、临时代码。与传统密码不同，传统密码是静态的，直到用户更改，而 OTP 是动态的，并在发出后很快过期，通常在几分钟内。由于其动态特性，即使 OTP 被恶意方拦截，OTP 也能显著提高安全性并大大降低未经授权访问的风险。 10 | 11 | OTPs 通常使用基于时间同步或数学计算的算法生成，确保每个代码都是唯一和不可预测的。用户通常通过短信、电子邮件、移动应用或硬件令牌接收 OTP。 12 | 13 | ## OTP (一次性密码) 的常见用例有哪些？ 14 | 15 | 以下是 OTP 的一些主要用途： 16 | 17 | ### 无密码登录 18 | 19 | 许多网站和应用程序现在提供无密码登录选项以增强安全性和用户便利性。用户可以请求将 OTP 发送到其注册的手机号码或电子邮件，以验证其身份，而无需记住复杂的密码。这种方法不仅简化了登录过程，还减少了与密码相关的漏洞风险。 20 | 21 | ### 密码恢复 22 | 23 | 在用户忘记密码的情况下，OTP 作为账户恢复的安全方法。用户可以请求 OTP，将其发送至注册的电子邮件或电话号码，以验证身份，然后重置密码。此过程有助于确保只有合法账户所有者才能进行恢复。 24 | 25 | ### 多因素认证 (MFA) 26 | 27 | OTPs 是多因素认证 (MFA) 的重要组成部分，MFA 将用户知道的东西（如密码）与用户拥有的东西（如移动设备）结合在一起。用户在输入其主要密码后，会收到一个 OTP，必须输入该 OTP 才能获得访问权限。这一额外的安全层显著降低了未经授权访问的可能性，即使主要密码被泄露也是如此。 28 | 29 | ### 敏感交易确认 30 | 31 | 对于涉及敏感数据或重大交易的活动（如在线银行业务或大额购买），OTP 作为一种安全措施确认用户同意。在完成这些操作之前，会将 OTP 发送到用户注册的联系方法中，用户必须输入该 OTP 才能完成交易。这确保了即使有人获得了用户的账户访问权，也无法在没有 OTP 的情况下执行关键操作。 32 | 33 | 34 | -------------------------------------------------------------------------------- /src/content/terms/zh/resource-owner.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 资源所有者 (Resource owner) 3 | tags: [oauth 2.0] 4 | description: 资源所有者是一个身份（通常是用户），能够授予对受保护资源的访问权限。在 OAuth 2.0 中，资源所有者可以授权客户端代表他们访问资源服务器中的资源。 5 | --- 6 | 7 | ## 什么是资源所有者 (Resource owner)？ 8 | 9 | 在 的上下文中，资源所有者是一个身份（通常是用户），可以授予对受保护资源（例如数据、文件或服务）的访问权限。 10 | 11 | 例如，你有一个名为 MyApp 的 Web 应用程序，想要访问用户的 Google Drive。以下是一个典型的 OAuth 2.0 流程： 12 | 13 | ```mermaid 14 | sequenceDiagram 15 | participant User 16 | participant MyApp 17 | participant Google 18 | 19 | User->>MyApp: 打开 MyApp 并点击 "连接 Google Drive" 20 | MyApp->>Google: 重定向到 Google
并附带授权请求 21 | Google->>User: 登录 Google 22 | User->>Google: 登录 23 | Google->>User: 请求访问 Google Drive 的权限 24 | User->>Google: 授予 MyApp 访问权限 25 | Google->>MyApp: 重定向到 MyApp 并附带授权数据（例如，访问令牌） 26 | MyApp->>Google: 使用访问令牌访问用户的 Google Drive 27 | ``` 28 | 29 | 在这个流程中，**用户**是授予 MyApp 访问其 Google Drive 的**资源所有者**，而 **MyApp** 是想要访问受保护资源的 ，**Google** 则同时是 和 。 30 | 31 | 顾名思义，资源所有者在 中拥有一些资源，并且可以在 上下文中授权客户端代表他们访问这些资源。 32 | 33 | ## 为什么资源所有者很重要？ 34 | 35 | 在 过程中，资源所有者是不可或缺的，因为他们是明确授予或拒绝访问其资源的主体。出于技术和合规性原因，资源所有者的同意是强制性的： 36 | 37 | - **技术**：资源所有者的同意确保客户端拥有访问资源的必要权限。与其进行全有或全无的访问，资源所有者可以根据客户端的请求授予部分访问权限。另一方面，资源所有者也可以在任何时候明确撤销访问权限。这种方法为 提供了明确且可审计的方式。 38 | - **合规**：在许多司法管辖区中，资源所有者的同意是法律要求，尤其是在处理敏感数据时。例如，《通用数据保护条例 (GDPR)》要求数据主体（资源所有者）必须对数据处理活动提供明确的同意。 39 | 40 | ## 资源所有者 vs. 资源服务器 41 | 42 | 资源服务器 负责托管和提供**受保护的资源**。它们是验证访问令牌并向客户端提供资源的看门人。 43 | 44 | 另一方面，根据 策略，资源所有者可能对资源服务器中的受保护资源拥有全部或部分控制权。 45 | 46 | 47 | 48 | 53 | -------------------------------------------------------------------------------- /src/content/terms/zh/role.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 角色 3 | tags: [authorization] 4 | description: 角色是基于角色的访问控制 (RBAC) 系统中的核心概念，代表一组定义用户可以执行哪些操作的权限，为管理和分配用户访问权限提供了一种有效的方法。 5 | --- 6 | 7 | ## 角色 8 | 9 | 角色是 中的核心组件之一。它作为可以分配给用户的权限的容器，充当用户和其访问权限之间的中介。 10 | 11 | ```mermaid 12 | graph LR 13 | Users 14 | -->|分配给| Roles 15 | -->|包括| Permissions 16 | ``` 17 | 18 | 一个典型的角色结构包含一个名称和一组权限： 19 | 20 | ```typescript 21 | const role = { 22 | name: 'order_admin', 23 | permissions: [ 24 | 'read:orders', // 查看订单详情 25 | 'write:orders', // 编辑订单 26 | 'read:products' // 查看产品 27 | ] 28 | } 29 | ``` 30 | 31 | > [!Note] 32 | > 角色主要用于权限管理。对于访问控制的实现，建议直接检查权限而不是角色。有关更多信息，请参见 。 33 | 34 | -------------------------------------------------------------------------------- /src/content/terms/zh/saml.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 安全断言标记语言 (Security Assertion Markup Language, SAML) 3 | tags: [authentication, authorization] 4 | description: 安全断言标记语言 (Security Assertion Markup Language, SAML) 是一种基于 XML 的标准，用于在身份提供者和服务提供者之间交换认证 (authentication) 和授权 (authorization) 数据。 5 | --- 6 | 7 | ## 什么是 SAML？ 8 | 9 | SAML（通常被称为 SAML 2.0）是一种基于 XML 的标准，用于在两个方之间交换认证 (authentication) 和授权 (authorization) 数据： 和 。它广泛用于身份联合和 解决方案。 10 | 11 | 顾名思义，SAML 传递关于用户身份和属性的断言。这些断言经过数字签名，并可选地加密以确保其完整性和机密性。 12 | 13 | ## SAML 如何工作？ 14 | 15 | 在深入了解 SAML 认证 (authentication) 流程之前，我们需要了解身份提供者和服务提供者如何识别和信任彼此。这种信任通过元数据交换建立，其中双方共享以下信息： 16 | 17 | - **实体 ID**：身份提供者或服务提供者的唯一标识符。 18 | - **公钥**：用于验证 SAML 断言中的数字签名。 19 | - **端点**：用于不同 SAML 操作的 URL，例如认证请求和响应。 20 | 21 | 一旦建立信任，SAML 认证 (authentication) 流程就可以进行： 22 | 23 | ```mermaid 24 | sequenceDiagram 25 | participant U as 用户 26 | participant SP as 服务提供者 (SP) 27 | participant IdP as 身份提供者 (IdP) 28 | 29 | U->>SP: 尝试访问服务 30 | Note over SP: 用户未认证 31 | SP->>U: 重定向到 IdP 32 | 33 | U->>IdP: SAML 认证 (authentication) 请求 34 | Note over IdP: 验证用户身份 35 | 36 | IdP->>SP: 认证 (authentication) 成功 37 | IdP-->>SP: 发送 SAML 断言 38 | 39 | Note over SP: 验证 SAML 断言 40 | SP->>SP: 处理断言并提取用户身份 41 | SP->>U: 认证成功 42 | ``` 43 | 44 | ### RelayState 45 | 46 | 在 SAML 流程中，`RelayState` 参数用于在认证 (authentication) 过程中保持用户状态。它作为用户在被重定向到身份提供者之前的原始请求的引用。服务提供者可以使用此参数在成功认证 (authentication) 后将用户重定向回原始页面或资源。 47 | 48 | RelayState 还用于防止 攻击，确保用户在认证 (authentication) 后正确重定向回原页面。 49 | 50 | ### SAML 断言 51 | 52 | SAML 断言是 SAML 协议的核心组件。它们包含关于用户的身份、属性和认证 (authentication) 状态的信息。SAML 断言有三种类型： 53 | 54 | - **认证 (authentication) 断言**：表明用户已被身份提供者认证 (authentication)。 55 | - **属性断言**：包含关于用户的附加信息，例如角色、权限和个人资料数据。 56 | - **授权决策断言**：指定用户对特定资源的访问权限。 57 | 58 | ## 采用 SAML 的注意事项 59 | 60 | 自 2000 年代初出现以来，SAML 已在企业环境中得到广泛采用。以下是在你的应用中采用 SAML 时的一些关键考虑因素： 61 | 62 | - 复杂性：与现代框架如 和 相比，SAML 实现可能较复杂。 63 | - 传输效率：由于 XML 格式，SAML 消息可能很大，会影响网络性能。 64 | - 安全性：必须保护 SAML 断言不被篡改和窃听。确保你的 SAML 实现遵循加密和数字签名的最佳实践。 65 | 66 | 尽管有这些考虑，SAML 仍然是一个用于安全身份联合和单点登录 (single sign on) 解决方案的强大且广泛使用的标准。然而，对于新应用或服务，你可能想考虑现代替代方案，如 OAuth 2.0 和 OpenID Connect，以获取更轻量且开发者友好的认证 (authentication) 和授权 (authorization) 方法。 67 | 68 | 69 | 70 | -------------------------------------------------------------------------------- /src/content/terms/zh/scope.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 作用域 (Scope) 3 | tags: [authorization] 4 | description: 作用域 (Scope) 定义了应用程序请求用户访问其受保护资源的权限。它是 OAuth 2.0 和 OIDC 中的一个基本概念，用于控制应用程序可以对用户数据进行的访问级别。 5 | --- 6 | 7 | ## 什么是作用域 (Scope)？ 8 | 9 | 在 和 协议中，**作用域 (Scope)** 是一种限制应用对用户资源访问的机制。它定义了应用程序向用户请求的权限。 10 | 11 | 作用域 (Scope) 由授权服务器定义，并表示为字符串。当应用程序请求访问用户资源时，它会在授权请求中指定所需的作用域 (Scope)。用户随后将在授权过程中被提示授予或拒绝这些权限。 12 | 13 | ### 为什么使用作用域 (Scope)？ 14 | 15 | - **细粒度访问控制**：作用域 (Scope) 允许应用程序仅请求执行特定操作所需的权限，降低未经授权访问的风险。 16 | - **用户同意**：作用域 (Scope) 帮助用户了解应用程序将访问哪些数据以及访问的原因。 17 | - **安全性**：作用域 (Scope) 有助于防止应用程序超出其访问权限，从而增强用户数据的安全性。 18 | 19 | ## 作用域 (Scope) 如何运作？ 20 | 21 | 当应用程序启动 OAuth 2.0 / OIDC 授权流程时，它会在授权请求中包含作用域 (Scope) 列表。授权服务器随后向用户呈现一个同意屏幕，列出请求的作用域 (Scope)。用户可以选择授予或拒绝对每个作用域 (Scope) 的访问。这一过程通常用于需要访问用户资源的第三方应用程序。 22 | 23 | 或者，如果应用程序被授权服务器信任，用户可能不会被提示同意，而是自动同意并授予所有请求的作用域 (Scope)。 24 | 25 | ## 定义作用域 (Scope) 26 | 27 | 作用域 (Scope) 通常由 API 提供者定义。它们可以是： 28 | - **标准作用域 (Standard scopes)**：由 OAuth 2.0 规范定义的常用作用域 (Scope)，由不同应用程序和服务共享。例如 `openid`、`profile`、`email`。 29 | - **自定义作用域 (Custom scopes)**：特定于某个应用程序或服务，根据其独特需求定制。例如 `read:orders`、`write:comments`。 30 | 31 | ## 作用域 (Scope) 在 OIDC 和身份管理中的用途 32 | 33 | 作用域 (Scope) 可以用于 OIDC 的多个方面，包括但不限于： 34 | 35 | - **身份验证 (Authentication)**：作用域 (Scope) 可用于在身份验证过程中请求特定的用户信息。例如 `profile`、`email`。 36 | - **授权 (Authorization)**：作用域 (Scope) 可用于请求访问特定资源或执行特定操作。例如 `read:orders`、`write:comments`。 37 | - **同意 (Consent)**：作用域 (Scope) 在同意屏幕中呈现给用户，以告知他们应用程序请求的权限。 38 | - **令牌签发 (Token issuance)**：作用域 (Scope) 包含在令牌响应中，以指示授予应用程序的权限。 39 | - **令牌验证 (Token validation)**：作用域 (Scope) 可用于在应用程序呈现令牌以访问受保护资源时验证其访问权。 40 | - **资源服务器 (Resource server)**：资源服务器可以使用作用域 (Scope) 来根据授予应用程序的权限实施访问控制策略。 41 | - **用户资料 (User profile)**：作用域 (Scope) 可用于请求超出基本声明的其他用户资料信息。 42 | 43 | ## 最佳实践 44 | 45 | - **请求最小作用域 (Minimal scopes)**：始终请求应用程序功能所需的最小作用域 (Scope) 集。这可以最大限度地降低过度授权的风险并增强用户信任。 46 | - **解释作用域 (Scope) 用途**：向用户明确解释每个作用域 (Scope) 的必要性。透明度有助于获得用户同意。 47 | - **尽可能使用标准作用域 (Standard scopes)**：利用标准作用域 (Scope) 以确保兼容性并减少复杂性。 48 | 49 | 50 | 51 | -------------------------------------------------------------------------------- /src/content/terms/zh/service-provider.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 服务提供者 (Service provider, SP) 3 | tags: [authentication, authorization] 4 | description: 服务提供者 (Service provider, SP) 是一个依赖于身份提供者 (IdP) 进行认证 (Authentication) 和授权的应用程序或服务。 5 | --- 6 | 7 | ## 什么是服务提供者 (Service provider, SP)？ 8 | 9 | 在 的领域中，服务提供者 (SP) （或在 的上下文中称为**依赖方**）是一个依赖于 进行认证 (Authentication) 和授权的应用程序或服务。它负责向用户提供服务，并根据身份提供者颁发的令牌来执行 策略。 10 | 11 | ```mermaid 12 | graph LR 13 | IdP[Identity Provider] 14 | SP["Service Provider
(Application, Service, API)"] 15 | IdP -->|认证用户| SP 16 | IdP -->|颁发令牌| SP 17 | IdP -->|提供用户信息| SP 18 | ``` 19 | 20 | ## 服务提供者标准 21 | 22 | 服务提供者没有严格的标准，因为它们可以是任何需要身份管理的类型的应用程序或服务。然而，服务提供者通常遵循其依赖的身份提供者设定的标准。例如，如果身份提供者支持 ，服务提供者通常会使用 OIDC 进行认证 (Authentication) 和授权。 23 | 24 | ## 服务提供者架构 25 | 26 | “服务提供者”这个术语并不指定特定的架构或实现。通常，服务提供者需要注册到身份提供者以建立信任并启用安全通信。注册过程通常涉及交换元数据和客户端凭证。 27 | 28 | 例如，在 OpenID Connect 的上下文中，服务提供者元数据通常包括： 29 | 30 | - **Client ID**：服务提供者的唯一标识符。 31 | - **Client secret**：用于认证服务提供者的共享密钥。 32 | - **重定向 URIs**：身份提供者在认证 (Authentication) 和授权后将用户重定向回去的 URI。 33 | 34 | 一旦注册，服务提供者可以通过将用户重定向到身份提供者指定的终端来启动认证 (Authentication) 过程。 35 | 36 | 当服务提供者为非交互式用例构建时，通常被称为需要 通信的 客户端。 37 | 38 | 39 | 40 | -------------------------------------------------------------------------------- /src/content/terms/zh/token-introspection.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 令牌内省 (Token introspection) 3 | tags: [oauth 2.0, oidc] 4 | description: 令牌内省 (Token introspection) 是 OAuth 2.0 的一个扩展，允许客户端查询授权服务器以验证访问令牌并检索其元数据。 5 | --- 6 | 7 | ## 什么是令牌内省 (token introspection)？ 8 | 9 | 令牌内省 (Token introspection) 是在 [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662) 中定义的 OAuth 2.0 扩展，允许客户端查询授权服务器以验证访问令牌并检索其元数据。此扩展在以下情况下非常有用： 10 | 11 | - 客户端希望实时验证访问令牌的有效性。 12 | - 访问令牌是不透明令牌（不是自包含的），需要授权服务器验证。 13 | 14 | ## 令牌内省 (Token introspection) 如何工作？ 15 | 16 | 以下是一个令牌内省 (token introspection) 请求的非规范示例： 17 | 18 | ```http 19 | POST /introspect HTTP/1.1 20 | Host: authorization-server.example.com 21 | Content-Type: application/x-www-form-urlencoded 22 | 23 | token=random-token-value 24 | &token_type_hint=access_token 25 | ``` 26 | 27 | `token_type_hint` 参数是可选的，应该设置为正在内省的令牌的类型。如果访问令牌是有效的，授权服务器将以该令牌的元数据进行响应： 28 | 29 | ```http 30 | HTTP/1.1 200 OK 31 | Content-Type: application/json 32 | 33 | { 34 | "active": true, 35 | "scope": "read write", 36 | "client_id": "client-id", 37 | "username": "johndoe", 38 | "token_type": "Bearer", 39 | "exp": 1634020800, 40 | "iat": 1634017200 41 | } 42 | ``` 43 | 44 | 值得注意的是，并非所有的授权服务器都支持令牌内省 (token introspection)，并且并非所有的令牌都可以内省。授权服务器可能会基于各种因素限制令牌内省 (token introspection) 的使用，例如，一些授权服务器可能不支持对JWT的内省。 45 | 46 | ### 令牌内省 (Token introspection) 请求中的关键参数 47 | 48 | 以下是一个令牌内省 (token introspection) 请求中的两个关键参数： 49 | 50 | - **`token`**: 要内省的令牌。 51 | - **`token_type_hint`**: 正在内省的令牌的类型。可以是 `access_token` 或 `refresh_token`。 52 | 53 | 54 | 55 | 61 | -------------------------------------------------------------------------------- /src/content/terms/zh/totp.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 基于时间的一次性密码 (Time-based one-time password, TOTP) 3 | tags: [authentication] 4 | description: 基于时间的一次性密码 (TOTP) 是一种通过使用当前时间作为关键因素的算法生成的临时唯一代码。 5 | --- 6 | 7 | ## 什么是 TOTP？ 8 | 9 | 基于时间的一次性密码 (TOTP) 是一种通过使用当前时间作为关键因素的算法生成的临时唯一代码。类似于通用的 ，TOTP 只能使用一次，但它有固定的生命周期，通常在 30 到 60 秒之间。到期后，会自动生成一个新代码。 10 | 11 | TOTP 标准由互联网工程任务组 (IETF) 在 [RFC 6238](https://datatracker.ietf.org/doc/html/rfc6238) 中定义，并广泛应用于各种双因素认证 (2FA) 和多因素认证 (MFA) 系统中。由于 TOTP 依赖于客户端（用户设备）和服务器之间的时间同步，它们提供了高度的安全性，并且难以预测或重用。 12 | 13 | ## TOTP 如何工作 14 | 15 | TOTP 的生成包括以下步骤： 16 | 17 | 1. 共享密钥：在初始设置期间，会生成一个共享密钥，并在客户端和服务器上安全存储。此密钥通常编码为二维码，用户可使用认证 (Authentication) 应用扫描该二维码。 18 | 2. 时间间隔：将当前时间划分为固定间隔，通常为 30 秒。 19 | 3. 算法应用：将共享密钥和当前时间戳输入基于散列的算法（通常为 HMAC-SHA1）以生成唯一的数字代码。 20 | 4. 同步：客户端和服务器使用相同的共享密钥和当前时间戳独立生成代码。只有在两者同步时，代码才匹配。 21 | 5. 验证：当用户登录或执行关键事务时，他们输入在其认证 (Authentication) 应用上显示的 TOTP。然后服务器将其与内部生成的 TOTP 进行比较以进行验证。 22 | 23 | ## 何时使用 TOTP 24 | 25 | 在大多数情况下，推荐使用普通的 OTP，但在无法“触发”新密码的情况下，建议使用 TOTP。 26 | 27 | - TOTP 示例：认证器应用 28 | - OTP 示例：电子邮件, 短信 29 | 30 | ## OTP 和 TOTP 有什么区别？ 31 | 32 | 主要区别在于 TOTP 是基于时间的，因此适用于设备未连接到服务器的情况。服务器可以轻松地向电子邮件地址或手机号发送新的密码，但这需要电子邮件或手机在线。然而，认证器应用可以保持离线并使用“时间”来验证密码。 33 | 34 | 35 | -------------------------------------------------------------------------------- /src/content/terms/zh/userinfo-endpoint.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 用户信息端点 (Userinfo endpoint) 3 | tags: [oidc] 4 | description: 用户信息端点 (Userinfo endpoint) 是一个 OpenID Connect (OIDC) 端点，为客户端提供用户信息。它是 ID 令牌 (ID token) 的补充端点，允许客户端检索额外的用户信息。 5 | --- 6 | 7 | ## 什么是用户信息端点 (Userinfo endpoint)？ 8 | 9 | 在 中，用户信息端点 (userinfo endpoint) 是 的一个端点，提供用户信息给 客户端。用户信息端点通常是 的补充端点，允许客户端检索 ID 令牌 (ID token) 中未包含的额外用户信息。 10 | 11 | 用户信息端点在 [OpenID Connect Core 规范](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) 中定义，通常在客户端获取到 ID 令牌 (ID token) 后被访问。 12 | 13 | ## 用户信息端点 (Userinfo endpoint) 如何工作？ 14 | 15 | 当客户端向用户信息端点发出请求时，它需要包含从 获得的访问令牌 (access token)，并使用 `GET` 或 `POST` HTTP 方法。用户信息端点验证访问令牌 (access token)，并在响应中返回用户信息。 16 | 17 | 以下是一个非规范的用户信息请求示例： 18 | 19 | ```http 20 | GET /userinfo HTTP/1.1 21 | Host: openid-provider.example.com 22 | Authorization: Bearer some-access-token 23 | ``` 24 | 25 | 不同 OpenID 提供者的用户信息端点路径可能会有所不同。你可以参考提供者的 找到用户信息端点 URL。如果访问令牌 (access token) 有效，用户信息端点将响应用户信息： 26 | 27 | ```http 28 | HTTP/1.1 200 OK 29 | Content-Type: application/json 30 | 31 | { 32 | "sub": "user123", 33 | "name": "Alice", 34 | "email": "alice@foo.com", 35 | "birthdate": "1990-01-01", 36 | "address": { 37 | "street": "1234 Elm St", 38 | "city": "Springfield", 39 | "country": "US" 40 | } 41 | } 42 | ``` 43 | 44 | 响应中可能包含各种用户属性，如 `name`、`email`、`birthdate` 和 `address`；通常，它包含比 更多的 声明 (claims)。实际返回的属性取决于 的配置和用户的同意。请参考你的 OpenID 提供者的文档以获取可用的具体属性。 45 | 46 | ### 签名和加密 47 | 48 | 用户信息响应可以被签名和/或加密以确保其完整性和保密性。如果应用了其中一种或两种保护，用户信息端点的响应将是一个 ，而不是纯 JSON 对象。 49 | 50 | -------------------------------------------------------------------------------- /src/env.d.ts: -------------------------------------------------------------------------------- 1 | /// 2 | /// 3 | 4 | interface ImportMetaEnv { 5 | STRAPI_URL: string; 6 | STRAPI_API_TOKEN: string; 7 | } 8 | -------------------------------------------------------------------------------- /src/icons/document.svg: -------------------------------------------------------------------------------- 1 | 2 | 5 | 6 | -------------------------------------------------------------------------------- /src/icons/external-link.svg: -------------------------------------------------------------------------------- 1 | 2 | 5 | 6 | -------------------------------------------------------------------------------- /src/icons/github.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 7 | 8 | 9 | -------------------------------------------------------------------------------- /src/icons/hacker-news.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | -------------------------------------------------------------------------------- /src/icons/hyperlink.svg: -------------------------------------------------------------------------------- 1 | 2 | 5 | 6 | 7 | -------------------------------------------------------------------------------- /src/icons/linked-in.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | -------------------------------------------------------------------------------- /src/icons/logto-logo.svg: -------------------------------------------------------------------------------- 1 | 8 | 13 | 14 | 22 | 23 | 24 | 25 | 26 | 27 | -------------------------------------------------------------------------------- /src/icons/reddit.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | -------------------------------------------------------------------------------- /src/icons/x.svg: -------------------------------------------------------------------------------- 1 | 2 | 5 | 6 | -------------------------------------------------------------------------------- /src/mdx-components/Img.astro: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /src/mdx-components/Ref.astro: -------------------------------------------------------------------------------- 1 | --- 2 | import { getEntry } from "astro:content"; 3 | import { Icon } from "astro-icon/components"; 4 | import { defaultLocale } from "astro-i18n-aut"; 5 | import { getLocaleFromUrl } from "../utils/locale"; 6 | 7 | type Props = { 8 | /** 9 | * The internal slug of the reference. It must be a valid slug of an article loaded in the site. 10 | * @see 'terms' collection in the 'src/content' directory. 11 | */ 12 | slug: string; 13 | /** 14 | * The optional heading ID to link to. If the article has no heading with the given ID, an error 15 | * will be thrown. 16 | */ 17 | headingId?: string; 18 | }; 19 | 20 | const locale = getLocaleFromUrl(Astro.url); 21 | const { slug: rawSlug, headingId } = Astro.props; 22 | const getEntryWithFallback = async () => { 23 | const entry = await getEntry("terms", `${locale}/${rawSlug}`); 24 | if (entry) { 25 | return entry; 26 | } 27 | 28 | if (locale !== defaultLocale) { 29 | const fallbackEntry = await getEntry( 30 | "terms", 31 | `${defaultLocale}/${rawSlug}`, 32 | ); 33 | if (fallbackEntry) { 34 | return fallbackEntry; 35 | } 36 | } 37 | 38 | throw new Error( 39 | `The article with slug "${rawSlug}" was not found in both ${locale} and ${defaultLocale} locales.`, 40 | ); 41 | }; 42 | const entry = await getEntryWithFallback(); 43 | const headings = await entry.render().then(({ headings }) => headings); 44 | const heading = headings.find((heading) => heading.slug === headingId); 45 | const slug = entry.slug.startsWith(`${defaultLocale}/`) 46 | ? entry.slug.slice(defaultLocale.length + 1) 47 | : entry.slug; 48 | 49 | if (headingId && !heading) { 50 | throw new Error( 51 | `The heading with ID "${headingId}" was not found in the article with slug "${entry.slug}".`, 52 | ); 53 | } 54 | --- 55 | 56 | 57 | 58 | 59 | {heading?.text ?? entry.data.title} 60 | 61 | 62 | 63 | 73 | -------------------------------------------------------------------------------- /src/mdx-components/SeeAlso.astro: -------------------------------------------------------------------------------- 1 | --- 2 | import Ref from "./Ref.astro"; 3 | import { getPhrases } from "../phrases"; 4 | import { getLocaleFromUrl } from "../utils/locale"; 5 | 6 | type Props = { 7 | /** 8 | * The internal slugs of the articles to be displayed in the "See also" section. 9 | * They must be valid slugs of articles loaded in the site. 10 | * @see 'terms' collection in the 'src/content' directory. 11 | */ 12 | slugs: string[]; 13 | }; 14 | 15 | const { slugs } = Astro.props; 16 | 17 | if (slugs.length === 0) { 18 | throw new Error('The "slugs" prop must contain at least one slug.'); 19 | } 20 | 21 | const locale = getLocaleFromUrl(Astro.url); 22 | const phrases = getPhrases(locale); 23 | --- 24 | 25 |

{phrases.content.see_also}

26 |
    27 | { 28 | slugs.map((slug) => ( 29 |
  • 30 | 31 |
    • 32 | )) 33 | } 34 |
35 | 36 | 42 | -------------------------------------------------------------------------------- /src/mdx-components/TextLink.astro: -------------------------------------------------------------------------------- 1 | --- 2 | import { Icon } from "astro-icon/components"; 3 | 4 | const isExternal = /^https:\/\//.test(Astro.props.href); 5 | const isAnchor = Astro.props.href.startsWith("#"); 6 | 7 | if (!isExternal && !isAnchor) { 8 | throw new Error( 9 | `The href "${Astro.props.href}" must be an external HTTPS URL or an anchor.`, 10 | ); 11 | } 12 | --- 13 | 14 | 15 | {isExternal && 16 | 17 | 18 | } 19 | {isAnchor && 20 | 21 | } 22 | 23 | 24 | 32 | -------------------------------------------------------------------------------- /src/pages/404.astro: -------------------------------------------------------------------------------- 1 | --- 2 | import Layout from "../layouts/Layout.astro"; 3 | import Topbar from "../components/Topbar.astro"; 4 | import FancyHr from "../components/FancyHr.astro"; 5 | import Footer from "../components/Footer.astro"; 6 | --- 7 | 8 | 9 | 10 | 11 |
12 |
13 |

404

14 |

Page not found

15 |
16 |
17 |
18 | 19 | 20 | 38 | -------------------------------------------------------------------------------- /src/pages/[lang]/[...slug]/cover.png.ts: -------------------------------------------------------------------------------- 1 | import type { APIRoute } from 'astro'; 2 | import { getCollection } from "astro:content"; 3 | import { defaultLocale } from "astro-i18n-aut"; 4 | import { chromium } from "playwright"; 5 | import pc from "picocolors" 6 | import pMap from "p-map"; 7 | import { buildCover } from '../../../utils/cover'; 8 | 9 | const getTimeString = () => { 10 | const now = new Date(); 11 | return `${ 12 | now.getHours().toString().padStart(2, '0') 13 | }:${ 14 | now.getMinutes().toString().padStart(2, '0') 15 | }:${ 16 | now.getSeconds().toString().padStart(2, '0') 17 | }`; 18 | }; 19 | 20 | export async function getStaticPaths() { 21 | const browser = await chromium.launch(); 22 | const terms = await getCollection("terms"); 23 | 24 | return pMap( 25 | terms, 26 | async ({ slug, data }) => { 27 | const [locale, ...rest] = slug.split("/"); 28 | const buffer = await buildCover(browser, data.title, locale ?? defaultLocale); 29 | const isDefaultLocale = locale === defaultLocale; 30 | 31 | console.log( 32 | pc.dim(getTimeString()), 33 | ' ', 34 | pc.green('✓'), 35 | pc.dim((isDefaultLocale ? `/${rest.join('/')}` : `/${slug}`) + '/cover.png'), 36 | ); 37 | return { 38 | params: isDefaultLocale ? { lang: rest.join('/') } : { lang: locale, slug: rest.join('/') }, 39 | props: { buffer }, 40 | } 41 | }, 42 | // Limit concurrency to avoid overwhelming the system 43 | { concurrency: 10 } 44 | ); 45 | } 46 | 47 | export const GET: APIRoute = async ({ props: { buffer } }) => { 48 | return new Response(buffer, { 49 | headers: { 50 | "Content-Type": "image/png", 51 | }, 52 | }); 53 | } 54 | -------------------------------------------------------------------------------- /src/pages/robots.txt.ts: -------------------------------------------------------------------------------- 1 | import type { APIRoute } from 'astro'; 2 | 3 | const getRobotsTxt = (sitemapURL: URL) => ` 4 | User-agent: * 5 | Allow: / 6 | 7 | Sitemap: ${sitemapURL.href} 8 | `; 9 | 10 | export const GET: APIRoute = ({ site }) => { 11 | const sitemapURL = new URL('sitemap-index.xml', site); 12 | return new Response(getRobotsTxt(sitemapURL)); 13 | }; 14 | -------------------------------------------------------------------------------- /src/phrases/ar.ts: -------------------------------------------------------------------------------- 1 | export const ar = Object.freeze({ 2 | general: { 3 | share: 'شارك', 4 | learn_more: 'اعرف المزيد', 5 | }, 6 | site: { 7 | description: 'Auth Wiki هو مجموعة شاملة من الموارد حول المصادقة والتفويض وإدارة الهوية والوصول. تعرف على OAuth 2.0 و OpenID Connect و SAML.', 8 | }, 9 | home: { 10 | description: 'استكشف واعثر على تعاريف واضحة لمصطلحات رئيسية متعلقة بالمصادقة والتفويض وإدارة الهوية والوصول (IAM). اعمل مع المعايير المفتوحة مثل OpenID Connect و OAuth 2.0 و SAML.', 11 | }, 12 | content: { 13 | what_is: 'ما هو {{title}}؟', 14 | edit_on_github: 'تحرير على جيثب', 15 | table_of_contents: 'جدول المحتويات', 16 | see_also: 'انظر أيضا', 17 | resources_and_references: 'الموارد والمراجع', 18 | } 19 | }); 20 | -------------------------------------------------------------------------------- /src/phrases/de.ts: -------------------------------------------------------------------------------- 1 | export const de = Object.freeze({ 2 | general: { 3 | share: 'Teilen', 4 | learn_more: 'Mehr erfahren', 5 | }, 6 | site: { 7 | description: 'Auth Wiki ist eine umfassende Sammlung von Ressourcen zu Authentifizierung, Autorisierung und Identitäts- und Zugriffsverwaltung. Erfahren Sie mehr über OAuth 2.0, OpenID Connect, SAML.', 8 | }, 9 | home: { 10 | description: 'Erkunden und finden Sie klare Definitionen wichtiger Glossare im Zusammenhang mit Authentifizierung, Autorisierung und Identitäts- und Zugriffsverwaltung (IAM). Arbeiten Sie mit Open-Standards wie OpenID Connect, OAuth 2.0 und SAML.', 11 | }, 12 | content: { 13 | what_is: 'Was ist {{title}}?', 14 | edit_on_github: 'Auf GitHub bearbeiten', 15 | table_of_contents: 'Inhaltsverzeichnis', 16 | see_also: 'Siehe auch', 17 | resources_and_references: 'Ressourcen und Referenzen', 18 | } 19 | }); 20 | -------------------------------------------------------------------------------- /src/phrases/en.ts: -------------------------------------------------------------------------------- 1 | export const en = Object.freeze({ 2 | general: { 3 | share: 'Share', 4 | learn_more: 'Learn more', 5 | }, 6 | site: { 7 | description: 'Auth Wiki is a comprehensive collection of resources about authentication, authorization, and identity and access management. Learn about OAuth 2.0, OpenID Connect, SAML.', 8 | }, 9 | home: { 10 | description: 'Explore and find clear definitions of key glossaries related to authentication, authorization, and identity and access management (IAM). Work with open-standards like OpenID Connect, OAuth 2.0, and SAML.' 11 | }, 12 | content: { 13 | what_is: 'What is {{title}}?', 14 | edit_on_github: 'Edit on GitHub', 15 | table_of_contents: 'Table of Contents', 16 | see_also: 'See also', 17 | resources_and_references: 'Resources and references', 18 | } 19 | }); 20 | -------------------------------------------------------------------------------- /src/phrases/es.ts: -------------------------------------------------------------------------------- 1 | export const es = Object.freeze({ 2 | general: { 3 | share: 'Compartir', 4 | learn_more: 'Más información', 5 | }, 6 | site: { 7 | description: 'Auth Wiki es una colección completa de recursos sobre autenticación, autorización y gestión de identidad y acceso. Aprenda sobre OAuth 2.0, OpenID Connect, SAML.', 8 | }, 9 | home: { 10 | description: 'Explore y encuentre definiciones claras de glosarios clave relacionados con la autenticación, autorización y gestión de identidad y acceso (IAM). Trabaje con estándares abiertos como OpenID Connect, OAuth 2.0 y SAML.', 11 | }, 12 | content: { 13 | what_is: '¿Qué es {{title}}?', 14 | edit_on_github: 'Editar en GitHub', 15 | table_of_contents: 'Tabla de contenidos', 16 | see_also: 'Ver también', 17 | resources_and_references: 'Recursos y referencias', 18 | } 19 | }); 20 | -------------------------------------------------------------------------------- /src/phrases/fr.ts: -------------------------------------------------------------------------------- 1 | export const fr = Object.freeze({ 2 | general: { 3 | share: 'Partager', 4 | learn_more: 'En savoir plus', 5 | }, 6 | site: { 7 | description: 'Auth Wiki est une collection complète de ressources sur l\'authentification, l\'autorisation et la gestion de l\'identité et des accès. Apprenez-en plus sur OAuth 2.0, OpenID Connect, SAML.', 8 | }, 9 | home: { 10 | description: 'Explorez et trouvez des définitions claires des glossaires clés liés à l\'authentification, l\'autorisation et la gestion de l\'identité et des accès (IAM). Travaillez avec des normes ouvertes comme OpenID Connect, OAuth 2.0 et SAML.', 11 | }, 12 | content: { 13 | what_is: 'Qu\'est-ce que {{title}}?', 14 | edit_on_github: 'Modifier sur GitHub', 15 | table_of_contents: 'Table des matières', 16 | see_also: 'Voir aussi', 17 | resources_and_references: 'Ressources et références', 18 | } 19 | }); 20 | -------------------------------------------------------------------------------- /src/phrases/index.ts: -------------------------------------------------------------------------------- 1 | import { ar } from './ar'; 2 | import { de } from './de'; 3 | import { en } from './en'; 4 | import { es } from './es'; 5 | import { fr } from './fr'; 6 | import { it } from './it'; 7 | import { ja } from './ja'; 8 | import { ko } from './ko'; 9 | import { nl } from './nl'; 10 | import { ptBr } from './pt-br'; 11 | import { ptPt } from './pt-pt'; 12 | import { zh } from './zh'; 13 | import { zhHant } from './zh-hant'; 14 | 15 | /** Display names for each locale. */ 16 | export const localeDisplay: Readonly> = Object.freeze({ 17 | ar: 'العربية', 18 | de: 'Deutsch', 19 | en: 'English', 20 | es: 'Español', 21 | fr: 'Français', 22 | it: 'Italiano', 23 | ja: '日本語', 24 | ko: '한국어', 25 | nl: 'Nederlands', 26 | 'pt-br': 'Português (Brasil)', 27 | 'pt-pt': 'Português (Portugal)', 28 | zh: '简体中文', 29 | 'zh-hant': '繁體中文', 30 | }); 31 | 32 | export const getPhrases = (locale: string) => { 33 | switch (locale) { 34 | case 'ar': 35 | return ar; 36 | case 'de': 37 | return de; 38 | case 'en': 39 | return en; 40 | case 'es': 41 | return es; 42 | case 'fr': 43 | return fr; 44 | case 'it': 45 | return it; 46 | case 'ja': 47 | return ja; 48 | case 'ko': 49 | return ko; 50 | case 'nl': 51 | return nl; 52 | case 'pt-br': 53 | return ptBr; 54 | case 'pt-pt': 55 | return ptPt; 56 | case 'zh': 57 | return zh; 58 | case 'zh-hant': 59 | return zhHant; 60 | default: 61 | throw new Error(`Unsupported locale: ${locale}`); 62 | } 63 | } 64 | -------------------------------------------------------------------------------- /src/phrases/it.ts: -------------------------------------------------------------------------------- 1 | export const it = Object.freeze({ 2 | general: { 3 | share: 'Condividi', 4 | learn_more: 'Scopri di più', 5 | }, 6 | site: { 7 | description: 'Auth Wiki è una raccolta completa di risorse sull\'autenticazione, l\'autorizzazione e la gestione delle identità e degli accessi. Scopri di più su OAuth 2.0, OpenID Connect, SAML.', 8 | }, 9 | home: { 10 | description: 'Esplora e trova definizioni chiare di glossari chiave relativi all\'autenticazione, all\'autorizzazione e alla gestione delle identità e degli accessi (IAM). Lavora con standard aperti come OpenID Connect, OAuth 2.0 e SAML.', 11 | }, 12 | content: { 13 | what_is: 'Cos\'è {{title}}?', 14 | edit_on_github: 'Modifica su GitHub', 15 | table_of_contents: 'Sommario', 16 | see_also: 'Vedi anche', 17 | resources_and_references: 'Risorse e riferimenti', 18 | } 19 | }); 20 | -------------------------------------------------------------------------------- /src/phrases/ja.ts: -------------------------------------------------------------------------------- 1 | export const ja = Object.freeze({ 2 | general: { 3 | share: '共有', 4 | learn_more: '詳細を見る', 5 | }, 6 | site: { 7 | description: 'Auth Wiki は、認証、認可、およびアイデンティティとアクセス管理に関する包括的なリソースのコレクションです。OAuth 2.0、OpenID Connect、SAML について学びます。', 8 | }, 9 | home: { 10 | description: '認証、認可、アイデンティティとアクセス管理（IAM）に関連する主要用語の明確な定義を探索して見つけます。 OpenID Connect、OAuth 2.0、および SAML などのオープンスタンダードと連携します。', 11 | }, 12 | content: { 13 | what_is: '{{title}} とは？', 14 | edit_on_github: 'GitHub で編集', 15 | table_of_contents: '目次', 16 | see_also: '関連項目', 17 | resources_and_references: 'リソースと参考文献', 18 | } 19 | }); 20 | -------------------------------------------------------------------------------- /src/phrases/ko.ts: -------------------------------------------------------------------------------- 1 | export const ko = Object.freeze({ 2 | general: { 3 | share: '공유', 4 | learn_more: '더 알아보기', 5 | }, 6 | site: { 7 | description: 'Auth Wiki는 인증, 권한 부여 및 식별 및 액세스 관리에 관한 종합적인 자료 모음입니다. OAuth 2.0, OpenID Connect, SAML에 대해 알아보세요.', 8 | }, 9 | home: { 10 | description: '인증, 권한 부여 및 식별 및 액세스 관리(IAM)와 관련된 주요 용어의 명확한 정의를 탐색하고 찾아보세요. OpenID Connect, OAuth 2.0, SAML과 같은 오픈 표준을 사용하세요.', 11 | }, 12 | content: { 13 | what_is: '{{title}}은(는) 무엇인가요?', 14 | edit_on_github: 'GitHub에서 편집', 15 | table_of_contents: '목차', 16 | see_also: '참고', 17 | resources_and_references: '리소스 및 참고', 18 | } 19 | }); 20 | -------------------------------------------------------------------------------- /src/phrases/nl.ts: -------------------------------------------------------------------------------- 1 | export const nl = Object.freeze({ 2 | general: { 3 | share: 'Delen', 4 | learn_more: 'Meer informatie', 5 | }, 6 | site: { 7 | description: 'Auth Wiki is een uitgebreide verzameling bronnen over authenticatie, autorisatie en identiteits- en toegangsbeheer. Leer over OAuth 2.0, OpenID Connect, SAML.', 8 | }, 9 | home: { 10 | description: 'Verken en vind duidelijke definities van belangrijke glossaria met betrekking tot authenticatie, autorisatie en identiteits- en toegangsbeheer (IAM). Werk met open standaarden zoals OpenID Connect, OAuth 2.0 en SAML.', 11 | }, 12 | content: { 13 | what_is: 'Wat is {{title}}?', 14 | edit_on_github: 'Bewerken op GitHub', 15 | table_of_contents: 'Inhoudsopgave', 16 | see_also: 'Zie ook', 17 | resources_and_references: 'Bronnen en referenties', 18 | } 19 | }); 20 | -------------------------------------------------------------------------------- /src/phrases/pt-br.ts: -------------------------------------------------------------------------------- 1 | export const ptBr = Object.freeze({ 2 | general: { 3 | share: 'Compartilhar', 4 | learn_more: 'Saiba mais', 5 | }, 6 | site: { 7 | description: 'Auth Wiki é uma coleção abrangente de recursos sobre autenticação, autorização e gerenciamento de identidade e acesso. Aprenda sobre OAuth 2.0, OpenID Connect, SAML.', 8 | }, 9 | home: { 10 | description: 'Explore e encontre definições claras de glossários-chave relacionados à autenticação, autorização e gerenciamento de identidade e acesso (IAM). Trabalhe com padrões abertos como OpenID Connect, OAuth 2.0 e SAML.', 11 | }, 12 | content: { 13 | what_is: 'O que é {{title}}?', 14 | edit_on_github: 'Editar no GitHub', 15 | table_of_contents: 'Sumário', 16 | see_also: 'Veja também', 17 | resources_and_references: 'Recursos e referências', 18 | } 19 | }); 20 | -------------------------------------------------------------------------------- /src/phrases/pt-pt.ts: -------------------------------------------------------------------------------- 1 | export const ptPt = Object.freeze({ 2 | general: { 3 | share: 'Compartilhar', 4 | learn_more: 'Saiba mais', 5 | }, 6 | site: { 7 | description: 'Auth Wiki é uma coleção abrangente de recursos sobre autenticação, autorização e gerenciamento de identidade e acesso. Aprenda sobre OAuth 2.0, OpenID Connect, SAML.', 8 | }, 9 | home: { 10 | description: 'Explore e encontre definições claras de glossários-chave relacionados à autenticação, autorização e gerenciamento de identidade e acesso (IAM). Trabalhe com padrões abertos como OpenID Connect, OAuth 2.0 e SAML.', 11 | }, 12 | content: { 13 | what_is: 'O que é {{title}}?', 14 | edit_on_github: 'Editar no GitHub', 15 | table_of_contents: 'Sumário', 16 | see_also: 'Veja também', 17 | resources_and_references: 'Recursos e referências', 18 | } 19 | }); 20 | -------------------------------------------------------------------------------- /src/phrases/zh-hant.ts: -------------------------------------------------------------------------------- 1 | export const zhHant = Object.freeze({ 2 | general: { 3 | share: '分享', 4 | learn_more: '了解更多', 5 | }, 6 | site: { 7 | description: 'Auth Wiki 是一個關於身份驗證、授權、身份和存取管理的綜合資源集合。了解 OAuth 2.0、OpenID Connect 和 SAML。', 8 | }, 9 | home: { 10 | description: '探索和查找與身份驗證、授權、身份和存取管理（IAM）相關的主要術語的明確定義。使用開放標準，如 OpenID Connect、OAuth 2.0 和 SAML。', 11 | }, 12 | content: { 13 | what_is: '{{title}} 是什麼？', 14 | edit_on_github: '在 GitHub 上編輯', 15 | table_of_contents: '目錄', 16 | see_also: '另見', 17 | resources_and_references: '資源和參考', 18 | } 19 | }); 20 | -------------------------------------------------------------------------------- /src/phrases/zh.ts: -------------------------------------------------------------------------------- 1 | export const zh = Object.freeze({ 2 | general: { 3 | share: '分享', 4 | learn_more: '了解更多', 5 | }, 6 | site: { 7 | description: 'Auth Wiki 是关于认证、授权、身份和访问管理的综合资源集合。了解 OAuth 2.0、OpenID Connect、SAML。', 8 | }, 9 | home: { 10 | description: '探索和找到与认证、授权、身份和访问管理（IAM）相关的关键术语的明确定义。使用开放标准，如 OpenID Connect、OAuth 2.0 和 SAML。', 11 | }, 12 | content: { 13 | what_is: '{{title}} 是什么？', 14 | edit_on_github: '在 GitHub 上编辑', 15 | table_of_contents: '目录', 16 | see_also: '另请参阅', 17 | resources_and_references: '资源和参考', 18 | } 19 | }); 20 | -------------------------------------------------------------------------------- /src/utils/locale.ts: -------------------------------------------------------------------------------- 1 | import { defaultLocale, locales } from "astro-i18n-aut"; 2 | 3 | const trimExtension = (path: string) => { 4 | return path.replace(/\.[^/.]+$/, ''); 5 | } 6 | 7 | export function getLocaleFromUrl(url: URL | string) { 8 | const [, lang] = trimExtension(new URL(url).pathname).split('/'); 9 | if (lang && lang in locales) { 10 | return lang; 11 | } 12 | return defaultLocale; 13 | } 14 | 15 | const getPathnameWithoutLocale = (pathname: string) => { 16 | if (!pathname.startsWith('/')) { 17 | throw new Error('Pathname must start with a slash'); 18 | } 19 | 20 | const [_, pathLocale, ...segments] = pathname.split('/'); 21 | 22 | if (pathLocale && pathLocale in locales) { 23 | return '/' + segments.join('/'); 24 | } 25 | return pathname; 26 | } 27 | 28 | const trimTrailSlash = (pathname: string) => { 29 | return pathname !== '/' && pathname.endsWith('/') ? pathname.slice(0, -1) : pathname; 30 | } 31 | 32 | export const getLocaleUrl = (url: URL | string, locale: string) => { 33 | const isInputPathname = typeof url === 'string' && (url.startsWith('/') || !url.includes(':/')); 34 | const pathname = getPathnameWithoutLocale( 35 | trimExtension(isInputPathname ? url : new URL(url).pathname) 36 | ); 37 | 38 | const newPathname = trimTrailSlash(locale === defaultLocale ? pathname : `/${locale}${pathname}`); 39 | if (isInputPathname) { 40 | return newPathname; 41 | } 42 | 43 | const urlObj = new URL(url); 44 | urlObj.pathname = newPathname; 45 | return urlObj.href; 46 | } 47 | -------------------------------------------------------------------------------- /src/utils/share.ts: -------------------------------------------------------------------------------- 1 | export const twitterShareUrl = 'https://x.com/share/'; 2 | export const linkedInShareUrl = 'https://www.linkedin.com/sharing/share-offsite/'; 3 | export const hackerNewsShareUrl = 'https://news.ycombinator.com/submitlink'; 4 | export const redditShareUrl = 'https://www.reddit.com/web/submit/'; 5 | 6 | export const buildTwitterShareUrl = (url: string, title: string) => { 7 | const shareUrl = new URL(twitterShareUrl); 8 | shareUrl.searchParams.set('url', url); 9 | shareUrl.searchParams.set('text', title); 10 | 11 | return shareUrl.href; 12 | }; 13 | 14 | export const buildLinkedInShareUrl = (url: string) => { 15 | const shareUrl = new URL(linkedInShareUrl); 16 | shareUrl.searchParams.set('url', url); 17 | 18 | return shareUrl.href; 19 | }; 20 | 21 | export const buildHackerNewsShareUrl = (url: string, title: string) => { 22 | // HackerNews doesn't support modern search params 23 | return `${hackerNewsShareUrl}?u=${encodeURIComponent(url)}&t=${encodeURIComponent(title)}`; 24 | }; 25 | 26 | export const buildRedditShareUrl = (url: string, title: string) => { 27 | const shareUrl = new URL(redditShareUrl); 28 | shareUrl.searchParams.set('url', url); 29 | shareUrl.searchParams.set('title', title); 30 | 31 | return shareUrl.href; 32 | }; 33 | 34 | 35 | export const buildShareUrlMap: Readonly string>> = Object.freeze({ 36 | x: buildTwitterShareUrl, 37 | 'linked-in': buildLinkedInShareUrl, 38 | 'hacker-news': buildHackerNewsShareUrl, 39 | reddit: buildRedditShareUrl, 40 | }) 41 | 42 | export const shareTitleMap: Readonly> = Object.freeze({ 43 | x: 'Share on X', 44 | 'linked-in': 'Share on LinkedIn', 45 | 'hacker-news': 'Share on HackerNews', 46 | reddit: 'Share on Reddit', 47 | }); 48 | -------------------------------------------------------------------------------- /src/utils/string.ts: -------------------------------------------------------------------------------- 1 | export const trimEnd = (str: string, suffix: string) => str.endsWith(suffix) ? str.slice(0, -suffix.length) : str; 2 | -------------------------------------------------------------------------------- /tsconfig.json: -------------------------------------------------------------------------------- 1 | { 2 | "extends": "astro/tsconfigs/strictest" 3 | } 4 | -------------------------------------------------------------------------------- /vitest.config.ts: -------------------------------------------------------------------------------- 1 | /// 2 | import { getViteConfig } from 'astro/config'; 3 | 4 | export default getViteConfig({ 5 | test: { 6 | // Vitest configuration options 7 | }, 8 | }); 9 | -------------------------------------------------------------------------------- /wrangler.toml: -------------------------------------------------------------------------------- 1 | name = "auth-wiki" 2 | pages_build_output_dir = "dist" 3 | compatibility_date = "2024-10-27" 4 | 5 | [env.production.vars] 6 | NODE_VERSION = "20" 7 | PNPM_VERSION = "9" 8 | --------------------------------------------------------------------------------