Need help with Appgyver app + jwtAuth + auth.php

[mevdschee]

@billiemead / @mevdschee

hello, hope you have time to give me a hint. (Big one). I'm posting this in this closed issue because is the same concept, but I can open a new one if it is the right way.

I'm doing a very basic Appgyver app (mobile) for dealing with my data in a PHP/MySql backend. I'm using apì.php from @mevdschee and got it to work decently. (By the way excellent job and thanks to Maurits). I'm bad at OOP but have some experience in procedural php (so I can follow the procedural part and do some minor changes) Now, my next goal is to have the app secured (in fact the data at the backend). We will be no more than four users (me and my brothers reach to three and one spare) but as an exercise I'm doing it with a db users table (without roles up to now). Because being an Appgyver mobile app I can´t rely on cookies for authentication (that took off dbAuth from the equation), and seems that token based authentication is my way. I do not like the idea of a static ApiKey. The options I'm looking at are jwtAuth and apiKeyDbAuth. Searching at the forums lead me to (also @mevdschee ) auth.php. At his point I reached @billiemead old post. So, as I read, auth.php with jwtAuth in api.php can be a solution.

1-Can I use these combination (auth.php+api.php with jwtAuth) without cookies at the mobile app front-end? I have seen that auth.php use session_start (maybe this session only travels auth.php<->api.php without reaching the mobile app)

2-Am I right thinking that my app will point to (post/get) auth.php instead of api.php (and auth.php will redirect to api.php)? I understand that I have to configure audience var in auth.php with value 'api.php' to do so. And have to point my front-end app to this new endpoint (adding auth.php in my previous endpoints paths, prior to api.php : example https://mydomain/..../auth.php/api.php/...)

3-Whats the _clientid concept in auth.php? Can I use one default for dealing with all my 4 users (expecting this), or I have to prearrange one _clientid for every db/app user? Is this _clientid the same that my db table _userid?

4-I wiil be able to redo the validate user function in auth.php (no clean OOP, just legacy procedures) with a connection to my db and searching my user to be verify. This way the cookies will be between the php programs and auth.php will connect front-end app and api.php with a token? Is this the right way?

5-@mevdschee , in this post you say : "You may use php-api-auth as a starter project to implement your own identity provider (if you don't want to use Auth0 or Firebase)." But in php-api-auth "I suggest that you first get PHP-CRUD-API working with Auth0 before you start implementing your own JWT based authentication provider using this repository."

6-@billiemead , do you have any progress with this that you mind to share?

That's all up to now Sure if you can answer I'll have more doubts, but that's gonna be a problem for the future me.

Thanks a lot GS

Originally posted by @gasalvati in https://github.com/mevdschee/php-crud-api/issues/661#issuecomment-1286962853

[mevdschee]

@gasalvati you have a brand-new account and you are hijacking an old post for your own issues. I don't like that.

1-Can I use these combination (auth.php+api.php with jwtAuth) without cookies

Yes you can, but why would you want to redo the authentication verification on every request? It is designed to be expensive.

2-Am I right thinking that my app will point to (post/get) auth.php instead of api.php?

No, only for the authentication you access auth.php and once you have retrieved the token you do the request to api.php with the token.

3-Whats the client_id concept in auth.php?

It is part of the spec of OAuth. Every client (implementation) has a client_id, helpful for a large SSO system.

4-I will be able to redo the validate user function in auth.php

Yes

5-@mevdschee , in this post you say :

Yes, and it is not a contradiction. Once you understand the Auth0 flow you can implement your own.

6-@billiemead , do you have any progress with this that you mind to share?

Don't expect free support from anyone, hire somebody to help you, your questions indicate that you need a lot of help.

[gasalvati]

Maurits Thanks for your reply. I won`t get back old issues (I was not sure about that) I won´t involve other users (neither knew that)

It seems I have a lot to think about.

Kind regards GS

[mevdschee]

You are welcome. I didn't mean to come across unwelcoming and reading my comment I think I did. My apologies for that. It works best if you can share the code that you have and make it easy for us to reproduce your setup. Then ask very specific questions about specific errors and/or breaking functionality. Most of the people here (including me) are very willing to help somebody that got stuck this way. You seem like a nice and grateful person and that is highly appreciated. Kindest regards, take care.. Maurits

[gasalvati]

Thanks

[nik2208]

referring to #910, I'll share my experience and my approach. PHP-CRUD-AUTH actually works as expected (once as @mevdschee says U understand the jwt auth flow). Once U define the structure of your project there are four actors playing:

• auth validator: auth.php will grant users asking this actor;
• auth.php: he will play the role we expect him to play;
• your project receiving the token and querying api.php
• api.php configuring jwtAuth as auth middleware.

Our auth validator (first actor) can be a single static function as it is in auth.php example or whatever entity returning true (user granted) or false (auth refused): upon that boolean value, auth.php will generate (or not generate, redirecting the user to the configured login page) the jwt token. As auth validator you can use (for instance) another instance of api.php setting dbAuth as auth method. This instance can actually point to the same db of the other (jwtAuth-based) instance: u can, better, u'd better restrict any action of this instance to the sole auth process (configuring properly the authorization handler).

Hope this helps ;)

[mevdschee]

Hope this helps ;)

I'm sure it does, I couldn't have explained it any better.

[nik2208]

furthermore, auth.php handles more than one configuration, so u can define multiple clients and multiple audience per client. This gives almost infinite possibilities. This is an example of configuration using an instance of api.php as validator:

main([
    'devel' => [
        'devel' => [
            'secret' => 'strongenoughhexstring',
            'login' => 'your login page', //serve it if static html, redirect to it if an app (react,vue, angular..)
        'loginError' =>'your error page', //as before, if an app u can use same login page with an error parameter like myapp.me/login?error=1
            'redirects' => 'the app u want to authorize',
            'validate' => function ($username, $password) {
        $url = "your dbAuth api.php instance link";
        $data = array('username' => $username, 'password' => $password);
        $options = array(
          'http' => array(
            'header'  => "Content-type: application/x-www-form-urlencoded",
            'method'  => 'POST',
            'content' => http_build_query($data)
          )
        );
        $context  = stream_context_create($options);
        $resp = file_get_contents($url, false, $context);
        preg_match('/([0-9])\d+/',$http_response_header[0],$matches);
        $responsecode = intval($matches[0]);
        return ($responsecode == 200);
            },
        ],
    ]
]);

[gasalvati]

Again thanks to you (both) and your share. As this is not a way of living but more a hobby I'll experiment with your guides and examples. It'll take some time to follow the learning path and as soon as I get my final result I will write down.

Till that moment, I will use a small php script for checking user against db table, granting access to the app and generating an apitoken at the same time in the same table, that token will be the one to validate api.php requests with apiKeyDbAuth.

Keep helping Best regards