Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
You can create a JWKSet object using three static methods:
JWKSet::createFromKeys(array $keys)
: creates a JWKSet using a list of JWK objects.
JWKSet::createFromJson(string $json)
: creates a JWKSet using a JSON object.
JWKSet::createFromKeyData(array $values)
: creates a JWKSet using a decoded JSON object.
Hereafter all methods available for a JWKSet object. The variable $jwkset
is a valid JWKSet object.
Please note a JWKSet object is an immutable object
We recommend you to avoid mixing public, private or shared keys in the same key set.
The algorithm management is part of the web-token/jwt-core
component:
For each cryptographic operation you will perform, you will need at least one algorithm.
The available algorithms depend on the cypher operation to be performed. Please refer to the Signed tokens or the Encrypted tokens to know more.
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
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. Let say:
Your application issues signed events,
Your application issues authentication tokens for registered users or a resource server.
To avoid mixing algorithms in one algorithm manager or instantiate several times the algorithms for several algorithm managers, this framework provides an Algorithm Manager Factory.
This factory will create algorithm managers on demand. It also 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 and 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
:
This framework comes with several signature algorithms. These algorithms are in the following namespace: Jose\Component\Signature\Algorithm
.
From v1.2, the algorithms have their own sub-packages. To avoid BC breaks, these packages are automatically installed for all v1.x of the framework. Starting at v2.0, you will have to explicitly install the algorithm packages you need.
HMAC with SHA-2 Functions. Package web-token/jwt-signature-algorithm-hmac
HS256
HS384
HS512
Elliptic Curve Digital Signature Algorithm (ECDSA). Package web-token/jwt-signature-algorithm-ecdsa
ES256
ES384
ES512
RSASSA-PKCS1 v1_5. Package web-token/jwt-signature-algorithm-rsa
RS256
RS384
RS512
RSASSA-PSS. Package web-token/jwt-signature-algorithm-rsa
PS256
PS384
PS512
Edwards-curve Digital Signature Algorithm (EdDSA) Package web-token/jwt-signature-algorithm-eddsa
EdDSA
(only with the Ed25519
curve)
Unsecured algorithm Package web-token/jwt-signature-algorithm-none
none
The following signature algorithms are experimental and must not be used in production unless you know what you are doing. They are proposed for testing purpose only.
They are all part of the package web-token/jwt-signature-algorithm-experimental
RS1
: RSASSA-PKCS1 v1_5 with SHA-1 hashing function.
HS1
: HMAC with SHA-1 hashing function.
These algorithms have to be used with the Algorithm Manager. They do not need any arguments.
Example:
This framework provides several components that will help you to use JWS (signed tokens) and JWE (encrypted tokens). It also provides other nice features to create and manage keys.
Before to start creating your first tokens, we have to create an algorithm manager and keys or key sets.
When your algorithm manager, your keys and your checkers are ready, you will be able to create or load your first tokens.
You can create a JWK object using two static methods:
JWK::create(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
This framework is able to create private and public keys easily using the JWKFactory
. It is available in the web-token/jwt-key-mgmt
component.
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
Note: for the none
algorithm, the framework 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).
The following feature was introduced in version 1.1.
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.
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.
When you receive a JWT (JWS or JWE), it is important to check its headers before any other action. In case something went wrong, the token has to be rejected.
To use the header checker, install the corresponding component:
The header parameters are checked by a Header Checker Manager. This manager can contain several header checkers.
Please note that:
the header parameter crit
(critical) is always checked.
even if the JWS and JWE Loaders will check the alg
/enc
header parameters, it is interesting to check them through this manager.
To create a header checker manager, you will need to add header checkers and at least one token type. You will find token type classes for the JWS and JWE tokens in the web-token/jwt-signature
and web-token/jwt-encryption
components respectively.
In the following example, we want to check the alg
header parameter for the signed tokens (JWS) received by our application.
The usage of this class is pretty easy you just have to call the check
method. The first parameter is the JWT to check, the second one is the index of the signature/recipient.
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 Header Checker Manager Factory will help you to create as many Header Checker Manager as you want to fit on your application requirements.
with the previous examples, we will only check the alg
(algorithm) header parameter. But your application may use other header parameters e.g. cty
, typ
...
The following header checkers are provided:
AlgorithmChecker
: checks the alg
header parameter.
AudienceChecker
: checks the aud
header parameter. This is a replicated claim as per the RFC7516 section 5.3
UnencodedPayloadChecker
: checks the b64
header parameter. See unencoded payload for more information.
If you need, you can create you own header checker. It must implement the interface Jose\Component\Checker\HeaderChecker
. In the following example, we will check that the protected header parameter custom
is an array with value foo
or bar
.
JSON Web Tokens can be used to transport any kind of data. They are mainly used to transport claims. When you receive a tokens that contains claims, it is important to check the values of these claims.
The Claim Checker Manager is responsible of this task. To use it, install the corresponding component:
In the following example, we will create a manager able to check the aud
(Audience), iat
(Issued At), nbf
(Not Before) and exp
(Expiration) claims.
When instantiated, call the method check
to check the claims of a JWT object. This method only accept an array. You have to retrieve this array by converting the JWT payload.
In some cases, it could be interesting to reject tokens that do not contain some mandatory claims. A list of mandatory claims can be set as second argument. If one of those claims is missing an exception is thrown, even if the claim have not been checked.
In the following example, an exception will be thrown if the iss
, sub
or aud
claim is missing.
Your application may use other claims that you will have to check therefore custom claim checkers have to be created.
In this example, we will create a class that will check the claim foo
. The claim accept only a string with the value bar
or bat
. All claim checker have to implement the interface Jose\Component\Checker\ClaimChecker
;
All done! Now you can instantiate your class and add it to your Claim Checker Manager.
The RFC7516 section 5.3 allows to replicate some claims in the header. This behaviour is very useful with encrypted tokens as it helps to reject invalid tokens without decryption of the payload.
The Claim Checker Manager cannot check those replicated claims, you have to create a custom header checker. However, to avoid duplicated classes, your claim checker can implement the Jose\Component\Checker\HeaderChecker
interface.
Have a look at the IssuedAtChecker
or the NotBeforeChecker
classes. These checkers can be used for claim and header checks.
Your application may use JSON Web Tokens in different contexts and thus the meaning of a claim may be different. You will need several Claim Checker Managers with dedicated claim checkers.
This framework provides an Claim Checker Manager Factory. This factory is able to accept as many claim checkers as you need. Each claim checker you add to this factory is associated to an alias. You will then be able to create a claim checker manager using those aliases.
To use the signed tokens (JWS), you have to install the web-token/jwt-signature
component.
This component provides lot of signature algorithms and classes to load and create signed tokens.
Please refer to this signature algorithm table to know what algorithms are available.
Then, you will find an example to create a signed token here and another example to load and verify incoming tokens.
This framework comes with several encryption algorithms. These algorithms are in the following namespaces:
Jose\Component\Encryption\Algorithm\KeyEncryption
: key encryption algorithms
Jose\Component\Encryption\Algorithm\ContentEncryption
: content encryption algorithms
From v1.2, the algorithms have their own sub-packages. To avoid BC breaks, these packages are automatically installed for all v1.x of the framework. Starting at v2.0, you will have to explicitly install the algorithm packages you need.
Key Encryption
Package web-token/jwt-encryption-algorithm-aeskw
A128KW
A192KW
A256KW
Package web-token/jwt-encryption-algorithm-aesgcmkw
A128GCMKW
A192GCMKW
A256GCMKW
Package web-token/jwt-encryption-algorithm-dir
dir
(class Dir
)
Package web-token/jwt-encryption-algorithm-ecdh-es
ECDH-ES
(class ECDHES
) READ THE NOTE BELOW
ECDH-ES+A128KW
(class ECDHESA128KW
) READ THE NOTE BELOW
ECDH-ES+A192KW
(class ECDHESA192KW
) READ THE NOTE BELOW
ECDH-ES+A256KW
(class ECDHESA256KW
) READ THE NOTE BELOW
Package web-token/jwt-encryption-algorithm-pbes2
PBES2-HS256+A128KW
(class PBES2HS256A128KW
)
PBES2-HS384+A192KW
(class PBES2HS384A192KW
)
PBES2-HS512+A259KW
(class PBES2HS512A1256KW
)
Package web-token/jwt-encryption-algorithm-rsa
RSA1_5
(class RSA15
) READ THE NOTE BELOW
RSA-OAEP
(class RSAOAEP
)
RSA-OAEP-256
(class RSAOAEP256
)
Content Encryption
Package web-token/jwt-encryption-algorithm-aesgcm
A128GCM
A192GCM
A256GCM
Package web-token/jwt-encryption-algorithm-aescbc
A128CBC-HS256
(class A128CBCHS256
)
A192CBC-HS384
(class A192CBCHS384
)
A256CBC-HS512
(class A256CBCHS512
)
IMPORTANT NOTE:
The algorithms ECDH-ES*
are not recommended unless used with the OKP
key type.
The following signature algorithms are experimental and must not be used in production unless you know what you are doing. They are proposed for testing purpose only.
They are all part of the package web-token/jwt-encryption-algorithm-experimental
Key Encryption
A128CTR
, A192CTR
and A256CTR
: AES CTR based encryption.
Chacha20+Poly1305
: Please note that this algorithm requires OpenSSL 1.1
RSA-OAEP-384
and RSA-OAEP-512
: Same algorithm as RSA-OAEP-256 but with SHA-384 and SHA-512 hashing functions.
Content Encryption
AxxxCCM-16-128
, AxxxCCM-16-64
, AxxxCCM-64-128
, AxxxCCM-64-64
: AES-CCM based aalgorithms. xxx can be 128 or 256.
Example:
By default, PBES2*
algorithms use the following parameter values:
Salt size: 64 bytes (512 bits)
Count: 4096
You may need to use other values. This can be done during the instantiation of the algorithm:
Example with 16 bytes (128 bits) salt and 1024 counts:
To use the encrypted tokens (JWE), you have to install the .
This component provides lot of encryption algorithms and classes to load and create encrypted tokens.
Please refer to to know what algorithms are available.
Then, you will find an and another incoming tokens.
Now that you have an algorithm manager and a key, it is time to create your first signed token.
The computation is done by the JWSBuilder
object. This object requires the algorithm manager and a JSON converter. In the following example, we will use the standard converter provided by the framework.
Now let's create our first JWS object.
Great! If everything is fine you will get a JWS object with one signature. We want to send it to the audience. Before that, it must be serialized.
We will use the compact serialization mode. This is the most common mode as it is URL safe and very compact. Perfect for a use in a web context!
All good! The variable $token
now contains a string that should be something like this:
Other serialization modes exist. We will see them in the Advanced Topics section.
The computation of a JWE is done by the JWEBuilder
object. This object requires the following services:
an algorithm manager with key encryption algorithms
an algorithm manager with content encryption algorithms
a compression method manager. No compression method is needed if you do not intent to compress the payload
and a JSON converter.
Now let's create our first JWE object.
Great! If everything is fine you will get a JWE object with one recipient. We want to send it to the audience. Before that, it must be serialized.
We will use the compact serialization mode. This is the most common mode as it is URL safe and very compact. Perfect for a use in a web context!
All good! The variable $token
now contains a string that should be something like that: eyJhbGciOiJBMjU2S1ciLCJlbmMiOiJBMjU2Q0JDLUhTNTEyIiwiemlwIjoiREVGIn0.9RLpf3Gauf05QPNCMzPcH4XNBLmH0s3e-YWwOe57MTG844gnc-g2ywfXt_R0Q9qsR6WhkmQEhdLk2CBvfqr4ob4jFlvJK0yW.CCvfoTKO9tQlzCvbAuFAJg.PxrDlsbSRcxC5SuEJ84i9E9_R3tCyDQsEPTIllSCVxVcHiPOC2EdDlvUwYvznirYP6KMTdKMgLqxB4BwI3CWtys0fceSNxrEIu_uv1WhzJg.4DnyeLEAfB4I8Eq0UobnP8ymlX1UIfSSADaJCXr3RlU
.
Encrypted tokens are loaded by a serializer or the serializer manager and decrypted by the JWEDecrypter
object. This JWEDecrypter object requires several services for the process:
an algorithm manager with key encryption algorithms
an algorithm manager with content encryption algorithms
a compression method manager. No compression method is needed if you do not intent to compress the payload.
In the following example, we will use the same assumptions as the ones used during the .
Now we can try to deserialize and decrypt the input we receive. We will continue with the result we got during the JWE creation section.
Note: we do not check header parameters here, but it is very important to do it. This step is described in the Header Checker section.
OK so if not exception is thrown, then your token is loaded and the payload correctly decrypted.
To avoid duplication of code lines, you can create a JWELoader
object. This object contains a serializer, a decrypter and an optional header checker (highly recommended).
In the following example, the JWELoader
object will try to unserialize the token $token
, check the header parameters and decrypt with the key $key
.
If the decryption succeeded, the variable $recipient
will be set with the recipient index and should be in case of multiple recipients. The method returns the JWE object.
In case you use a key set, you can use the method loadAndDecryptWithKeySet
.
This feature was introduced in version 1.1.
The JWELoaderFactory
object is able to create JWELoader
objects on demand. It requires the following factories:
JWESerializerManagerFactory
JWEDecrypterFactory
HeaderCheckerManagerFactory
(optional)
Signed tokens are loaded by a serializer or the serializer manager and verified by the JWSVerifier
object. This JWSVerifier object just requires an algorithm manager.
In the following example, we will try to load a signed token. We will only use the HS256
algorithm.
Now we can deserialize the input we receive and check the signature using our key. We will continue with the data we got in the JWS creation section.
Note: we do not check header parameters here, but it is very important to do it. This step is described in the Header Checker section.
The method verifyWithKey
returns a boolean. If true, then your token signature is valid. You can then check the claims (if any) using the claim checker manager.
To avoid duplication of code lines, you can create a JWSLoader
object. This object contains a serializer, a verifier and an optional header checker (highly recommended).
In the following example, the JWSLoader
object will try to unserialize the token $token
, check the header parameters and verify the signature with the key $jwk
. The variable $payload
corresponds to the detached payload (null
by default).
If the verification succeeded, the variable $signature
will be set with the signature index and should be in case of multiple signatures. The method returns the JWS object.
In case you use a key set, you can use the method loadAndVerifyWithKeySet
.
This feature was introduced in version 1.1.
The JWSLoaderFactory
object is able to create JWSLoader
objects on demand. It requires the following factories:
JWSSerializerManagerFactory
JWSVerifierFactory
HeaderCheckerManagerFactory
(optional)
To perform cryptographic operations (signature/verification and encryption/decryption), you will need keys. The keys can be grouped in key sets.
The JWK
and JWKSet
objects are part of the web-token/jwt-core
component:
A JWK object represents a key. It contains all parameters needed by the algorithm and also information parameters.
This framework is able to create private and public keys easily. It can also generate those keys from external resources.
Read to know how to create your keys.
A JWKSet object represents a key set. It can contain several keys.
We recommend you to avoid mixing public, private or shared keys in the same key set.
Please refer to to know how to create and use the key sets.
The algorithm RSA1_5
is deprecated due to known .
These algorithms have to be used with the . They do not need any arguments.