Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This framework needs at least:
PHP 8.1+,
Extensions:
MBString
JSON
Depending on the algorithms you using, other PHP extensions may be required (e.g. OpenSSL, Sodium).
Please note that cypher operation may be really slow, especially RSA functions. It is highly recommended to enable GMP or BCMath.
This project is a framework that provides an implementation of:
It also provides:
a Symfony bundle
a standalone console application
This project is release under MIT licence.
For each cryptographic operation, you will need at least one algorithm and one key.
The algorithm list depends on the cypher operation to be performed (signature or encryption).
These algorithms are managed by an Algorithm Manager. In the following example, we will create an algorithm manager that will handle two algorithms: PS256
and ES512
. See signature or encryption algorithm pages for more information.
It is not possible to set the same algorithm twice in the same algorithm manager.
Your application may need several algorithm managers for several use cases. For example you application may use JWT for:
signed events,
authentication tokens.
To avoid mixing algorithms in one algorithm manager or instantiate several times the same algorithms, this framework provides an Algorithm Manager Factory.
This factory will create algorithm managers on demand. It allows the same algorithm to be instantiated multiple times but with different configuration options.
Each algorithm is identified using an alias.
The first argument of the method add
is the alias for the algorithm. It must be unique. In general, this alias corresponds to the algorithm name.
As you can see in the example, we added the algorithm PBES2-HS512+A256KW
twice:
with the default configuration,
with custom arguments.
Now our algorithm manager factory is ready. We can create several algorithm managers by passing a list of aliases to the method create
:
To perform cryptographic operations (signature/verification and encryption/decryption), you will need cryptographic keys.
A JWK object represents a key. It contains all parameters needed by the algorithm and may also provide information parameters.
This framework is able to create private and public keys easily. It can also generate those keys from external resources such as binary key files or certificates.
The keys can be grouped in key sets. A JWKSet
object represents a key set. It can contain as many keys as you need.
We strongly recommend you to avoid mixing public, private or shared keys in the same key set.
You can create a JWK object using two static methods:
new JWK(array $values)
: creates a JWK using direct values.
JWK::createFromJson(string $json)
: creates a JWK using a JSON object.
Hereafter all methods available for a JWK object. The variable $jwk
is a valid JWK object.
Please note a JWK object is an immutable object. If you change a value using a setter, it will return a new object.
This framework is able to create private and public keys on the fly using the JWKFactory
. 4 types of keys are supported:
Symmetric Key:
oct
: octet string
Asymmetric Key:
RSA
: RSA key pair
EC
: Elliptic Curve key pair
OKP
: Octet key pair
The none
algorithm needs a key of type none
. This is a specific key type that must only be used with this algorithm.
The following example will show you how to create an oct
key.
Additional parameters will be set to limit the scope of this key (e.g. signature/verification only with the HS256
algorithm).
If you already have a shared secret, you can use it to create an oct
key:
The following example will show you how to create a RSA
key.
The key size must be of 384 bits at least, but nowadays the recommended size is 2048 bits.
The following example will show you how to create a EC
key.
The supported curves are:
P-256
P-384
P-521
(note that this is 521 and not 512)
The following example will show you how to create a OKP
key.
The supported curves are:
Ed25519
for signature/verification only
X25519
for encryption/decryption only
The none
key type is a special type used only for the none
algorithm.
In case you already have key values, you can create a key by passing those values as an argument:
You can convert a PKCS#1 or PKCS#8 key file into a JWK. The following method supports PEM and DER formats. Encrypted keys are also supported.
You can convert a PKCS#12 Certificate into a JWK. Encrypted certificates are also supported.
You can convert a X.509 Certificate into a JWK.
Please note that X.509 certificates only contains public keys.
JWS or JWE objects support every input that can be encoded into JSON:
string
, array
, integer
, float
...
Objects that implement the \JsonSerializable
interface such as JWK
or JWKSet
The detached payload is supported.
Compact
YES
YES
Flattened JSON
YES
YES
General JSON
YES
YES
Deflate (DEF
)
YES
Compression is not recommended. Please avoid its use. See RFC8725 for more information.
oct
YES
Symmetric keys
RSA
YES
RSA based asymmetric keys
EC
YES
Elliptic Curves based asymmetric keys
OKP
YES
Octet Key Pair based asymmetric keys
JWK objects support JSON Web Key Thumbprint (RFC 7638).
A none
key type for the none
algorithm. It is used to explicitly allow this unsecured algorithm.
JWKSet is fully supported.
HS256
HS384
HS512
YES
ES256
ES384
ES512
YES
RS256
RS384
RS512
YES
PS256
PS384
PS512
YES
GMP or BCMath extension is highly recommended
none
YES
Please note that this is not a secured algorithm. USE IT WITH CAUTION!
EdDSA with Ed25519 curve
YES
SODIUM extension is highly required
EdDSA with Ed448 curve
NO
No extension or built-in implementation available
Other signature algorithms like RS1
, HS1
or HS256/64
are also available. These algorithms should be used for testing purpose only or for compatibility with old systems
dir
YES
RSA1_5
RSA-OAEP
RSA-OAEP-256
YES
GMP or BCMath extension is highly recommended Read note below!
ECDH-ES
ECDH-ES+A128KW
ECDH-ES+A192KW
ECDH-ES+A256KW
YES
spomky-labs/aes-key-wrap
is required for *KW algorithms
ECDH-SS
ECDH-SS+A128KW
ECDH-SS+A192KW
ECDH-SS+A256KW
YES
spomky-labs/aes-key-wrap
is required for *KW algorithms
A128KW
A192KW
A256KW
YES
spomky-labs/aes-key-wrap
is required
PBES2-HS256+A128KW
PBES2-HS384+A192KW
PBES2-HS512+A256KW
YES
spomky-labs/aes-key-wrap
is required
A128GCMKW
A192GCMKW
A256GCMKW
YES
spomky-labs/aes-key-wrap
is required
ECDH-ES with X25519 curve
YES
SODIUM extension is highly required
ECDH-ES with X448 curve
NO
No extension or built-in implementation available
Other encryption algorithms like RSA-OEAP-384
or ChaCha20-Poly1305
are also available. These algorithms should be used for testing purpose only or for compatibility with old systems
The algorithms RSA1_5
and RSA-OAEP
are now deprecated. Please use with caution.
A128CBC+HS256
A192CBC+HS384
A256CBC+HS512
YES
A128GCM
A192GCM
A256GCM
YES
Other encryption algorithms like A128CTR
, A192CTR
and A256CTR
are also available. These algorithms should be used for testing purpose only or for compatibility with old systems
When you receive a JWT (JWS or JWE), it is important to check ALL headers parameters BEFORE any other action. In case something went wrong, the token should be rejected.
This is a strong recommendation, there are known vulnerabilities on tokens that are processed without header verification.
Please note that some algorithms may use additional header parameters. Please read carefully the details on the signature or encryption algorithms page.
The header parameters are checked by a Header Checker Manager. This manager can contain several header checkers.
The header parameter crit
(critical) is always checked.
Even if the cypher process will check the alg
/enc
header parameters, it is interesting to check them before to reject tokens earlier.
To create a header checker manager, you will need to add header checkers and at least one token type.
In the following example, we want to check the alg
header parameter for the signed tokens (JWS) received by our application.
You can then call the check
method.
The first parameter is the JWT to check,
The second one is the index of the signature/recipient. It could be ignored if you are not using the Flattened or General JSON Serialization Modes.
In some cases, it could be interesting to reject tokens that do not contain some mandatory header parameters. A list of mandatory parameters can be set as third argument. If one of those parameters is missing an exception is thrown, even if that header parameter have not been checked.
In the following example, an exception will be thrown if the alg
, enc
or crit
parameters is missing.
The library provides several header checker classes you can instantiate and use at will. They are all located in the namespace Jose\Component\Checker
.
AlgorithmChecker
alg
No
AudienceChecker
aud
No
ExpirationTimeChecker
exp
Yes
IssuedAtChecker
iat
Yes
IssuerChecker
iss
No
NotBeforeChecker
nbf
Yes
UnencodedPayloadChecker
b64
No