OAuth & JSON Web Tokens
I am not updating these docs because my focus is on my new PHP Serverless Project.
My LaSalle Software's purpose was always a mixture of learning, marketing, and a basis for my own projects. It has, and is, fulfilling these purposes magnificently!
As always, contact me with your questions.
-Bob
My LaSalle Software's purpose was always a mixture of learning, marketing, and a basis for my own projects. It has, and is, fulfilling these purposes magnificently!
As always, contact me with your questions.
-Bob
I use OAuth 2.0 to let the back-end know that a request from the front-end is ok.
The only place where I use this stuff right now is the blog, where the front-end asks the admin back-end for the blogging data via endpoints.
OAuth is a specification, not an implementation (say this out loud three times). I use OAuth 2.0 specs, but exactly how I implement these specs is up to me. These are the specs that I use in my LaSalle Software. OAuth and JWT documentation is fraught with Terminolus Confusilitis, so hang in there!
➧ client credentials grant
➧ confidential client types (I like the video in this link)
➧ bearer token
➧ JSON web token
No, I do not use Laravel's Sanctum package. This came out well after I did my OAuth2 implementation. Although I have not tried this, if the need arises, we should be able to use Sanctum in tandem with my OAuth2 implementation.
Yes, I did take a good hard look at Laravel's Passport package.
Here is the key (pun intended) to my OAuth2 implementation:
(1) control both the front-end and the back-end
(2) Both the front-end and the back-end can know the "key"
(3) "key" is used to encrypt the JWT
(4) the front-end creates a JWT, and then encrypts this JWT using a key
(5) the back-end un-encrypts the JWT using the same key that the front-end uses
(6) this key that both "sides" know is supposed to be just their own little secret. Hence the synonym "secret"
A popular package for JWT designed for Laravel is the Tymon Designs package. The core of this package is the lcobucci/jwt package. I use Luis Cobucci package directly.
The front-end's "secret" key is in the .env file:
The initial "secret" key is done for you during installation. You should change your "secret" key regularly.
The back-end's "secret" key is in the database:
Note that they are the same "secret" key!
The back-end needs to store one "secret" key for each front-end. That's why I use the database.
This is how the "secret" key looks in the admin:
This is where the front-end creates its JWT.
This is where the back-end processes the JWT.
The only place where I use this stuff right now is the blog, where the front-end asks the admin back-end for the blogging data via endpoints.
OAuth is a specification, not an implementation (say this out loud three times). I use OAuth 2.0 specs, but exactly how I implement these specs is up to me. These are the specs that I use in my LaSalle Software. OAuth and JWT documentation is fraught with Terminolus Confusilitis, so hang in there!
➧ client credentials grant
➧ confidential client types (I like the video in this link)
➧ bearer token
➧ JSON web token
No, I do not use Laravel's Sanctum package. This came out well after I did my OAuth2 implementation. Although I have not tried this, if the need arises, we should be able to use Sanctum in tandem with my OAuth2 implementation.
Yes, I did take a good hard look at Laravel's Passport package.
Here is the key (pun intended) to my OAuth2 implementation:
(1) control both the front-end and the back-end
(2) Both the front-end and the back-end can know the "key"
(3) "key" is used to encrypt the JWT
(4) the front-end creates a JWT, and then encrypts this JWT using a key
(5) the back-end un-encrypts the JWT using the same key that the front-end uses
(6) this key that both "sides" know is supposed to be just their own little secret. Hence the synonym "secret"
A popular package for JWT designed for Laravel is the Tymon Designs package. The core of this package is the lcobucci/jwt package. I use Luis Cobucci package directly.
The front-end's "secret" key is in the .env file:
The initial "secret" key is done for you during installation. You should change your "secret" key regularly.
The back-end's "secret" key is in the database:
Note that they are the same "secret" key!
The back-end needs to store one "secret" key for each front-end. That's why I use the database.
This is how the "secret" key looks in the admin:
This is where the front-end creates its JWT.
This is where the back-end processes the JWT.