authentication - What type of token/auth to use for non-interactive API clients in an OIDC context? -
we consider using openid connect id tokens authentication of our public api.
these usage scenarios we'd cover:
- web ui (single page, client-side javascript app)
- command line interface (cli) used in interactive session
- cli used non-interactively, e. g. in ci/cd pipeline
- other api calls executed in non-interactive session
the idea (1) , (2) use oidc implicit grant type, user authenticates interactively (username/password) @ our openid connect identity provider , permits rp (relying party, client) access users identity. identity provider issue short-lived id token, refresh token , (optionally?) access token rp.
for (3) , (4) interactive authentication out of question. we'd instead issue tokens users allow them access our api on behalf. these tokens should long living, invalidated when deleted in system.
still, want use jwt id tokens issued identity provider carrier of identity information api requests internally.
my questions are:
- can done purely 1 of tokens issued openid connect implicit grant type?
- can access token issued in long-lived (no expiry, invalidated deleting system) way , exchanged client against id token?
- or refresh token thing use that?
- or have solve outside openid connect? leaves question how resolve opaque tokens api requests against identity details (jwt) use in our api/services?
if use implicit flow (for scenarios 1 , 2), can't use refresh tokens. need client credentials (client id , secret) request refresh tokens. in implicit flow, don't store client credentials.
when client public client (spa,etc..), not safe store client secret in it. public clients use implicit flow. implicit flow doesn't support refresh tokens. of oidc libraries implement silent token renewal/refresh feature circumvent absence of refresh tokens. there limitations model (you need have active session idp renewal working without interruption)
tl;dr -> if client public client, use implicit flow (which don't need client secret access tokens idp). implicit flow doesn't support refresh tokens.
can done purely 1 of tokens issued openid connect implicit grant type?
it not possible use refresh tokens implicit flow. authorization code flow supports refresh tokens can't used spa clients. need combination of oauth 2.0/oidc flows.
can access token issued in long-lived (no expiry, invalidated deleting system) way , exchanged client against id token?
these 2 different things:
- "invalidated deleting system" : discussing self-contained tokens vs reference tokens.
self-contained tokens: these tokens contains information required validate authenticity in - e.g. issuer details, validity, etc.. client don't need make back-channel call sts confirm authenticity. these tokens hard revoke , valid duration specified in token.
reference tokens: reference tokens opaque tokens contains guid identifier in , no other details. in order validate authenticity of these tokens, client needs make back-channel call sts. 1 main advantage can revoked deleting corresponding identifier in sts db.
- "exchanged client against
id tokenrefresh token" - assuming referring refresh tokens instead of id token. use refresh token purpose
or refresh token thing use that?
yes. refer above comments
or have solve outside openid connect? leaves question how resolve opaque tokens api requests against identity details (jwt) use in our api/services?
if use opaque tokens, oidc/oauth 2.0 has several endpoint (like userinfo) further information user. can use introspection endpoint know validity of token.
(scenarios 3 , 4): not sure how plan use - non-interactive client(which acting on own , not behalf of user), should use client credentials flow.
if client want act on behalf of user, should enable way user approve behavior.
Comments
Post a Comment