Class ExplicitExternalTokenProvider
- All Implemented Interfaces:
ExternalTokenProvider
This is the case the platform was actually designed around: a workload that obtained a token from its own authorization server - in its own code, with its own client registration - and now wants to spend it here. It has the token in hand; there is nothing to fetch.
It is also the shortest-lived source, and that is a property rather than a defect. The token
this provider holds does not refresh, so a process that outlives it will start failing. A workload
that needs to keep running past one external token's lifetime configures the file or command
source, or supplies its own ExternalTokenProvider that re-reads from wherever its token
actually lives.
-
Constructor Summary
ConstructorsConstructorDescriptionTakes a defensive copy of the supplied token so the caller's ownclosedoes not empty this provider. -
Method Summary
Modifier and TypeMethodDescriptiondescribe()A short operator-facing description of WHERE the token comes from - a path, a command name, an issuer - for diagnostics.Produces the current external token.kind()Which of the configured source kinds this provider is, ornullfor a consumer-supplied provider that is none of them.toString()Names the kind and reveals nothing, so an accidental log statement leaks nothing.Methods inherited from class java.lang.Object
equals, getClass, hashCode, notify, notifyAll, wait, wait, waitMethods inherited from interface co.ankatech.ankasecure.sdk.auth.ExternalTokenProvider
close, invalidate
-
Constructor Details
-
ExplicitExternalTokenProvider
Takes a defensive copy of the supplied token so the caller's ownclosedoes not empty this provider.- Parameters:
token- the externally minted token; not retained, not closed, and not modified- Throws:
NullPointerException- iftokenisnullIllegalArgumentException- iftokenis empty
-
-
Method Details
-
fetchExternalToken
Description copied from interface:ExternalTokenProviderProduces the current external token.How current it is belongs to the implementation, and the two answers are both correct for their case. A provider that READS an out-of-band token re-reads on every call, because something else refreshes it and a copy held here is a copy that expires without anyone noticing. A provider that OBTAINS the token itself knows the lifetime its issuer stated for it, so it may reuse one inside that lifetime - and when the issuer states no lifetime, it falls back to fetching per call rather than guessing one.
- Specified by:
fetchExternalTokenin interfaceExternalTokenProvider- Returns:
- the token; the caller takes ownership and closes it
-
kind
Description copied from interface:ExternalTokenProviderWhich of the configured source kinds this provider is, ornullfor a consumer-supplied provider that is none of them.- Specified by:
kindin interfaceExternalTokenProvider- Returns:
- the kind, or
nullwhen the provider is the consumer's own
-
describe
Description copied from interface:ExternalTokenProviderA short operator-facing description of WHERE the token comes from - a path, a command name, an issuer - for diagnostics. It must never contain the token.- Specified by:
describein interfaceExternalTokenProvider- Returns:
- the description; never
null
-
toString
Names the kind and reveals nothing, so an accidental log statement leaks nothing.
-