NativePHP Mobile: Login/Register with Email/Password or Google

Hello guys, native PHP is getting more and more popular and I decided to get back to this topic and shoot this video about how to perform sign in with Google or with email and password in native PHP. And this is exactly what you will see now on YouTube, but also I published this lesson in my course on native PHP, the last new lesson, login and register with email, password and Google. And with new improvements in native PHP, I will probably expand this course even more in later months. So, I will link that in the description below. But for now, how to build login and registration forms in your mobile applications with native PHP. Welcome back to this course about native PHP. I'm shooting this video roughly 1 month after the full course is done because some people asked me questions and I decided to dig deeper into how to perform login and register in native PHP application with the remote API where users actually reside in the database. In other words, how to implement something like this. So, login and register form and also in two ways with email and password or with socialite. So, sign in with Google for example. In this video, I will show you our version how we implemented it with our team of Laravel Daily. And this is only our version. I'm not an expert. I'm not a mobile first developer. So, maybe some developers would call me out on something rightfully so. But our version does work and I will show you step by step how to implement it. Also important note that authentication mechanism you will see in this video will not work with native PHP jump. Jump is for quick start off application but it has some plugins disabled some features disabled. So for full authentication especially with signing with Google you need to have the application built which I did already as APK to my Android phone. So first thing you need to understand that there are two repositories now. Native PHP repository with the mobile application with the routes login and register which is basically the mobile page that you saw just a minute ago. But then when you submit the form it calls the API so separate repository of only API which I installed here on Laravel forge with real URL. So we can visit here's the homepage. I updated it to Laravel 13 as well. So basically we're calling slash API/V1 authentication of that API Laravel repository from another Laravel repository which is native PHP. So that register page is a livewire component single file component with name email and password as property and first I will show you without Google and then sign in with Google is a separate topic later in this video. So we have HTML form with wires submit register with wire model name and email and password. So on this screen down below I will click register and then I land on this form. I will fill that in and show you how it works. So I have this form filled and I will click register, create account and the account is created on the server. Then I have the token. I will show you how it works in a minute and then I'm inside of quiz application. Now in the code in the native PHP livewire component register method performed this first device identity is a service inside of our native PHP application which is working with device plugin of native PHP free plug-in like device get ID and other functions from that service we need device info for identifying that device. So device name the model basically and then we call post to a register from the API that HTTP API is a macro in app service provider. This one basically we're calling HTTP HTTP base URL which is this that I showed you in the browser and then the actual endpoint is O register and then we either receive the token or some connection exception on the API. This is the code of API repository. In routes API, we have route post register into O controller which performs the registration after the validation and then it uses Laravel Sanctum on the back end and creates the token for that device name we pass from the front end. So from the API point of view, it's the same as you would work with any mobile client like React Native or Flutter or any other. You get the token returned and then it's your job on native PHP. how and where to store that token and how to validate it later. So let's get back to that part of the repository to the native PHP and this is important part. So we save the token and the token verification time in session in PHP session and this is the less secure way but free. So if you don't want to use any more external plugins or setup with native PHP you can store the token with session but it's not encrypted. it will probably not survive if you reinstall or even relaunch the application and there are a few more downsides but for smaller projects it may work. The more secure and probably the correct and the more recommended way is to have a plug-in installed native PHP called mobile secure storage and this is not a free plugin. This is the price at the moment on the right at the time of shooting this video and this is the new model of native PHP version 3. So they made the core functionality free of native PHP mobile, but their plan is to earn the money from paid plugins. So yes, it doesn't seem to be like a very low price, but by purchasing that, you're also supporting the guys to work more on native PHP. I don't get paid for this video for saying that, but I'm just sharing the information that this is more secure way encrypted storage which will survive reinstall and which is using the native way of encryption on the device. So hardware thing and even the example code snippet in the documentation of this plug-in is talking about that specific use case of storing O token. But for our demo project, we will proceed with session. I just wanted to tell you about this more secure plug-in way and then we redirect to home and then proceed with typical native PHP application and in the web we have this so it's a movie quiz application with these pages these screens which are protected by middleware authenticated so it's not a typical O we need to validate the token that we have on the device in the PHP session now what's inside this is the logic of that middleware We get the token from the session and then if we don't have that then we log out obviously and then we check if that token needs verification. This is kind of a personal preference. How do you verify the token? Or a better question, when do you verify it? Because a lot of operations in mobile applications are happening offline without the internet, without calling the API. So, it's kind of your personal choice of how often to ping the server to check if the token needs verification. The main part here is in the documentation of native PHP in the authentication section in bold they're saying this checking for token existence it's not enough so it's a bad practice to just check if the token exists then the middleware is passed no we need to check if the token needs verification for example you may set interval in this case we set 15 minutes so every 15 minutes it will call the API for reverification of token And if it's not verified then we clear the session and redirect to route login which is basically this. So we're again working with PHP session. Now verification of the token is calling off me endpoint of the API with that token as a parameter and then if response is successful we refresh the token verified time otherwise we return false. But also one more thing is connection exception. What happens if we're offline in the mountains somewhere or just without the network for that case try catch will fall on this part and then we have another check. So another parameter how long do you allow to stay offline and for example you have 24 hours this is reasonable amount in my experience. So if the token is not verified for more than 24 hours then return false will happen and automatically log out. Now again let's switch to back end and see how it's implemented on the back end in the routes API we have route middleware o sanctum powering this endpoint in the same o controller where we saw register and in fact we can take a look at login which is very similar so in login form you pass email and password and then the verification and then if it's successful we create a new token and return it to the native PHP client. Now me is a very simple endpoint. It just returns the JSON with the current user ID, name and email. And this is also a personal preference depending on which data you actually need in your application. You may just return 200 with empty data or just return the user ID something like that because what we need is actually the token and to verify if that token is bypassing the middleware of O sanctum here. So in this case it's kind of additional information which is not really needed in this case but sometimes it may be needed for some mobile clients. Then we can also take a look at login page. So the form here on top which is very similar actually to the registration. We have properties of liveware email and password login with Google. We will take a look at that in a minute. But login is basically submit of the form which is very very similar. HTTP API call and if it is successful we also save the session with token and verification time and in the HTML part is just form wire submit login and wire model email and other livewire properties but then down below on the same page we have this button login with Google wireclick login with Google and first I will demonstrate how it works it will basically log me in because I have already set my credentials made the request to approve my credentials in Google. So all it will do it will just log me in. So this is probably the best user experience to login on the web or on mobile without email and password. And how does it work with native PHP? So login with Google is a method also calling API but in a different way. So we're calling API URL Google redirect. Does it look familiar for you? If you have used Laravel socialite, this is exactly that. So we're using Laravel socialite on the back end and let me show you the rest. So off Google redirect will return us the URL and then in the native browser we will call this the backend code the API route is this. So we have redirect and we have Google controller and that redirect basically uses the socialite driver. So you set up your Google credentials and tokens in the console of Google like you do with Laravel socialite like you do with sign in with Google on the web same thing and then in the native PHP code browser o will open chrome instance the browser to redirect to and then the second part with the socialite if authentication with Google is successful then there's call back and in here you can see a weird URL with prefix native PHP The prefix is decided by yourself, but it's not HTTP. So you don't have the URL to call back from the server to launch the URL on your mobile device. This is not how it works. So have the prefix native PHP. This is the prefix for error for something goes wrong. But if it is successful again, we create the user or update it. We create the token and return it similar how we do with login and register. And then we redirect to native PHP O call back that native PHP thing in the mobile application repository. We go to routes web and we see this and the logic is similar. If we get the token, we store it in the session in this case and redirect to home screen. Now important part in the env you need to define that so-called deep link scheme in the native PHP official documentation about authentication. This is how it is described. It may be different. It may be my app, but it should be unique for your application on users devices. And that's basically it. As I told you, it's our version of how it worked for us with PHP session without external paid plug-in. But we can of course discuss in the comments below the alternatives, the implications, and what I may have missed in this native PHP setup or in general how mobile authentication may work better. The link to the repositories both mobile and APIs will be in the description below this video in the course. So yeah, that was the video from the course. The link to the repositories will be only in the course for premium members, not on YouTube. So subscribe to my Laravel daily premium membership to support my work. And also if you have any questions or ideas around native PHP, what other topics should I touch upon on this channel and in the course that I want to expand later in 2026? Let's discuss all of that in the comments below because the team of native PHP keep cooking new versions. So version 3.1 for mobile introduced 10x performance improvement and Android 8 support which is pretty old. So with all those new features, let's discuss what do you want me to talk about in the future. That's it for this time and see you guys in other