Don't understand Laravel Passport for API security.
I'm having a hard time understanding how passport is using OAuth2 to secure an API. We write an API, but how is a user accessing the API? I've never seen an API require manual intervention with a "accept/deny" for authorization codes before. I've only ever seen it used when logging in to a platform like Spotify (using facebook creds for example).
If someone wants to build their own software using our API, who exactly are we/they going to show the OAuth authorization screen to? It's simply for the software developer using our API to gain an access token everything should be programmatic.
Laravel Passport does offer the Oauth2 way of authorization a certain application to perform actions on your behalf. That's when you need to go to some website and confirm the authentication.
However, this is just one implementation of Oauth2. There is also a different way where you need to perform the extra handshake, but that is a complete API and programmatic approach.
Yes, the use case for us is that a client wants to develop software that interacts with their private user account on our system. Then they can expose that software to the public and it'll use the clients private user account to be authorized when it hits the endpoints that we expose. There should be no manual "Accept/Deny" buttons that I keep seeing whenever I try and look up oauth for API examples. They should be able to requests access and get a token to use.
Now for OAuth is this always required as a programmatic login first followed by a token request? Or can we issue them an "API Key" of sorts which they can use continuously? Does passport even support this or I am mixing up two different types of API authentication?
Ah I think I'm beginning to understand a bit better. @bobbybouwmann is that API key flow an example of using Personal Access Tokens? The user can generate themselves a token.
@bobbybouwmann I noticed creating a client requires a redirect_uri. It can't be left blank but it is of no use when this is also done by us and not by the consumer or user of the consumer. I guess this is just something we have to put in regardless.
The redirect_uri is only needed when you let the user authorize it in the browser. If you don't do that, the redirect_uri is not needed. You probably just need the Client Credentials token
