I am building an app which is having only two forms. The first form collect user information. There is no user login/registration involved. And the second form displays survey to be filled in by that user. I can not use passport as there is no login/registration involved . I should not even return sensitive data using any API endpoint.
I want to know which approach should I go for then?
I don't know anything about your application, but it sounds like you might want to use a unique token (for example: h38dhe9ajnq2093bdhgj20opdnwspo2a). I'm guessing you will be sending out links to people who will be filling out questionnaires or surveys, so include the token in your email/message so you can uniquely identify them. Once they initially come to your application, store the token in their session or in a client cookie, and base your authentication middleware on that being present in every request.
I'm assuming that security is not a big concern in this case. Otherwise, you may need to implement this system more carefully.
Related
I have a monolith web application powered by Laravel. Users access different forms and some of them have button on them that executes Ajax call to the back-end (example relative endpoint: api/external/get-current-temperature). A back-end function that handles the request than connects to an external service via API and obtain data, writes some log in database and pass data back to requestor (front-end user). But in order to execute any API call it has to authenticate and obtain a Token.
Question:
I have multiple users that can potentially request api/external/get-current-temperature at the same time. How should I handle authorization/token? Should I store it in database and check its expiration time before requesting a new one or what? How would I refresh it? - The external provide has no specific function that could be utilized to verify token. But I know for sure the token is valid 60 minutes.
The users of your application never have to be mixed up / mistaken with your foreign API. You can and should provide you own mechanism (i.e. tokens) to authenticate any users. If users are authenticated the external API is used, else an error-message could be provided by your application.
As users also fill several different form it's quite possible that you save some user-data. If every user has own authentication credentials it's easy and much more secure to provide only the user's own data. If you use for every user the same authentication token in your own application you might get the situation that one user can see data from another user.
So see it like this:
You / your application is the user of the external API, therefore you need only one authenticqation token for it. Your application users use the external API as a service and as that you should provide it in your app. The data though that are provided to the service might differ from user to user.
Example payment application:
The API is always the same, you as developer get an API key, but the payments are for every user of your application differently. As developer you might never even able to see, store or track the user-data that are exchanged between the foreign service and the user, but your app serves as hub and provides perhaps also some products or services that are considered in any payments.
I am building a Vue app that uses pure PHP (no PHP framework) for its back-end. For my authentication system, I thought that using jwt(JSON Web Tokens) could help me. So I searched the web and found this article and also this one to help me build a login-register system with the help of jwt. I have no problem in implementing these articles in my front-part (Vue) and back-part (PHP) of my app. Currently I can send a request when the user register to the site and send back a jwt to the front-part with the help of firebase php-jwt library.
But the main question comes here. As I know from Vue ecosystem one of the reasons that we use Vuex is to store some data (state) globally in our apps and without calling a server we could use them anywhere (or in any route) in our Vue apps.
By reading one of that two articles, I noticed that finally the jwt is stored in Vuex and when the user wants to see an authorized page (a page that needs Authorization) the Vue app checks the Vuex to see if the token exists or not and if it exists, the app allows the user to see that page.
By reading the second one I noticed that jwt is useful when the user sends request to the back-part of site. In that case jwt is decoded and if it is valid (for example the expiration date is OK or ...), the user can access to an authorized page.
With the description above what is the benefit of using jwt in my Vue app? If I store just the id and user-name of user, it could do the same task for me. In other words, If I want to ask my question clearly, the problem is when I want to use Vuex and not send request every time to the server, I don't need and can't benefit from jwt (am I right?). Similarly when I want to use jwt, I could not benefit from Vuex. Because I must send request each time to find that the jwt is valid or not and after that decide about the user.
If I understood correctly and there is a contradiction for using both jwt and Vuex, why there are so many tutorials that speak about authentication a Vue app with jwt? Also if my understanding about jwt is correct, does that mean that when the jwt is expired I must ask the user to login again and again (regardless of using or not using Vuex)?
Could anyone please help me to have a better understanding about this problem to have better decision about my authentication system?
With the description above what is the benefit of using jwt in my Vue app?
JWT is used in authentication. You could use cookie sessions if you want.
I don't think it has an impact on your app. Probably save you some few round trips if your JWT happens to contain some data you need like user id.
the problem is when I want to use Vuex and not send request every time to the server.
I am not sure how these two are related.
If you need to make a request, then why would you use Vuex?
Vuex is a state management library.
If you need to do a request, then do a request.
Vuex does not relate to JWT in any way.
If you decided to put your JWT token in Vuex then that's your decision. Some put it in browser's localStorage or cookies.
Similarly when I want to use jwt, I could not benefit from Vuex. Because I must send request each time to find that the jwt is valid or not and after that decide about the user.
There's a lot of things you can store in Vuex that you don't need to do a request first:
Global component states e.g Login/Signup modals, NavMenu, Audio/Video player
Category filters like you see in Amazon or any shop-related apps
I am not sure what you are doing that you need to send request each time to find out if jwt is valid or not.
If something needs to be done on server-side then it has to be done on server-side whether you use jwt or cookies.
Also if my understanding about jwt is correct, does that mean that when the jwt is expired I must ask the user to login again and again (regardless of using or not using Vuex)?
JWT is a format. If you use OAuth2 for example, there's "access token" and "refresh token". You can get another "access token" automatically with "refresh token" and so that might mean you don't need to show login form again.
You could also just refresh your JWT token each time if you want. I'm not sure about the implications of that but there's a lot you can do.
These links might help you:
https://stackoverflow.com/a/36932032/10975709
https://stackoverflow.com/a/45214431/10975709
My question for you is:
If you were not to use JWT and instead just use cookies, how would things differ? (Aside from the technical aspects like needing to refresh tokens)
You are probably approaching/thinking/using JWT the wrong way.
I'm building an SAAS with a single database. Tenant in this case is called site.
I want to achieve what Stackexchange does where it has a global login as well as a stackoverflow/softwareengineering/etc login. I'm not sure how to store users. A user can have many sites and sites can have many users. The problem with designing a JoinTable is that the user roles are stored in the User table (im using Symfony3.4). I want separate roles per site/tenant.
Another problem I'm trying to figure out is how to go about logging in. I'm using oAuth2 and to login in I sinply call {{url}}/oauth/v2/token?grant_type=password&client_id=client_id&client_secret=client_secret&username=admin&password=pass. How should I make the user log in to a specific tenant/site? Do I add site_id to the query parameters?
Thanks for reading.
This question is very broad, so I'll take a stab at it.
If you are building out a network of sites, each site would ideally have it's own database. This will ensure sandboxing and the ability to easily migrate a site to it's own infrastructure if needed due to scaling or security concerns.
When dealing with user authentication, it sounds like you'll want a single secure user store that acts as the oauth2 server and each of the sites act as a Oauth client. You'll want to use the Authorization Code flow grant type in OAuth.
Essentially, a user visits Site A. Site A sees they are not logged in via the site's session. It redirects to your OAuth server which shows a login (think of the google login). Since Site A also passed in a callback url, once you've signed in, the OAuth server knows where to redirect the user, along with the valid token information. Then Site A takes that token and exchanges it for an access token on the server-side so now you've got authentication data on Site A.
If you are going to implement your own OAuth handshaking, you should utilize an existing server/client library. For PHP, you can look at the League OAuth server library, or use Laravel Passport, if you're using Laravel. There are other similar packages for other frameworks out there.
I created an API to login in my web app. After checking the parameters, use the Auth method: loginUsingId() with the id of the user to be logged in.
After that I get authenticated correctly, in fact doing an echo Auth::user() shows the user property correctly.
However, by making a redirect to another project page, I am no longer logged in the portal and shows me the login page.
It seems that the user's session does not remain or that is not created at all.
I use Laravel 5.6. I have no middleware for the route.
Each time your page accesses the API, it's essentially talking to a brand new instance of the API.
Think of it like this. Your "login" endpoint is not actually telling the API to log someone in. It's telling it to merely verify the caller's claim that the given password belongs to the given user, end of story. If you want to turn that authentication into actual "login" behavior from the UI perspective, there's other steps you need to take.
If Laravel is serving up Blade files for your site, then it's a different story. Out-of-the-box, it generates a Php session for you, and sends the session-key cookie to the browser for use in subsequent requests.
Similar to a session-key, for maintaining a session between a website and a separate API, you need each subsequent call to include a token. And you need the login endpoint to provide that token upon successful authentication.
Passport is one way to go, but it might be overkill for your situation. Passport is good for handling users, clients, and authorization permissions. But if all you want is authentication and you're not as concerned with controlling what they have access to beyond that, then I highly recommend Tymon JWT-Auth.
Both Passport and JWT-Auth use "bearer tokens" in the 'Authorization' header. There're other kinds though, like "basic tokens". A basic token is just an encoded concatenation of the username and password. Laravel supports this with a route middleware, but I do still recommend going with JWT.
One of the nice things about JWT is you can actually include extraneous data within the token itself. And it positions you better to lean into Passport (OAuth2) if/when you need it, by not requiring your client-side to change its authentication method.
I am looking to implement SSO in all my future php/angular applications. I see there are services (Auth0, oauth.io, etc) that are sort of the middle man of an SSO app and there are protocols such as OAuth 1.0/2.0 but in regards to creating a custom SSO solution (using aforementioned OAuth protocols, I assume), I am a little foggy on the complete flow of the process.
What I do get:
App gets Access Token
(optional) App validates Access Token
App (with Access Token) gets access to a particular API and returns result. For
example, Facebook profile information.
What I don't get:
What to do with that information once I have it. Do I retain the access token and request information from the API source each time they login? How do I relate my own application data to the API data? Would I create a different kind of user record that just contains the access token and application's userid?
Do I retain the access token and request information from the API source each time they login?
If the token does not expire, you can hold on to it in a data store and use it with each request. Many times, though, the token will expire, and you need to request a new one each time you start a session. In this case you'd probably store the token in memory instead of a permanent storage location.
How do I relate my own application data to the API data?
I think we'd need to know a little more about your application to answer this question.
Would I create a different kind of user record that just contains the access token and application's userid?
Again, we'd probably need a little more information about your application. If you were persisting the token (in the case that it doesn't expire), then you need to make some considerations about how you want to store it. If not, you can probably just put it into a local variable or session.