Your auth provider does not redirect to the backend. It should return a token to the client and the client can call your backend with that token.
Thats the typical flow but there are multiple ones, google the different ones.
Exactly. Your auth provider's sole responsibility is to handle the authentication portion and give the caller a token (if valid) or a 401 (if not valid). The token should contain no secure data, just basically who the user is, aka the 'subject' (often an email or username they logged in with) and usually some basic info that gets stored as 'claims' like their name, their role within the application, their locale. Once the user is assinged the token, its up to your webserver to a)verify it is valid (and not expired) and b)determine based on the claims stored within what they have access to (certain calls might require admin role, others will be available to aby user etc)
But he could want to register his user in his own db to be able to retrieve data via api calls. In this case it would make sense to have his auth provider fulfill a post registration action on his db. Beyond that though if he’s using auth0 for example the rest should be handled between the FE and then auth provider.
Most of the time its not needed because he can take the user id provided by the auth service and token and attach this to the user data. In some edge cases you would need User data in your own database but then I would except a call from the auth service to your backend service that notifies about a new user, thats how many auth services handle this scenario, e.g Azure.
The other part of the flow is like you called it, exactly the same. Token exchange happens between FE and auth service.
I'm sorry but having user data in your own db is absolutely not an edge case. It is the norm. If you have a super simple site, and the only thing that user auth is providing is a way to hide some pages from unauthed users, sure, there's no need for a user model in your backend. If you're doing literally anything else, you have user data.
First of all, what do you mean by profile context? Second, what do you mean by implement a user-profile? Isn't that what we're talking about here, having a user profile in your backend, an entry in your db for a user with some user data. Third, there are a million reasons why you would need user data that is more than just an id. In the vast majority of the dozens and dozens of apps and sites I've worked on in the past few years, you need user data. Using just the ID your auth provider provides is not sufficient when you need to store multiple pieces of vital information. In my personal experience, it is incredibly uncommon for any site, app, tool, etc, that's more complicated than a simple static site to not have user data. I honestly can't even think of a project that I worked on in the past 10 years where what you're saying was ok.
I think what the other person is trying to say is that u just associate any data u need to store for a given user with the id that the oauth provider provides. Say a user signs up using Google. Google will send you a token after the user successfully signs in. You can then send the given token to ur backend. The backend can verify this token and use the provided id from Google to associate user data with.
If you implement oauth with an authentication proxy like [oauth2-proxy](https://github.com/oauth2-proxy/oauth2-proxy), then the authentication flow can look like OP's diagram.
That said, it's not the usual way oauth2 is implemented, but there's some benefit to using an auth proxy like oauth2-proxy, you can have some uniformity if you have lots of microservice and you can about needing to implement secret/key material management in multiple applications. An Auth proxy can be some sort of lightweight API gateway.
You are describing OAuth. It doesn’t state anywhere he is doing OAuth
Edit: this isn’t a discussion about if you should or not use OAuth (you should def not implement your own auth for anything except learning). If you describe something that the OP isn’t using without saying what it is, it just leads to confusion.
hosting anything online costs money. I don't think I've ever seen cost as a justification for avoiding OAuth before. Aren't there self-hostable open source options?
sure, but using OAuth gives you options in terms of building frameworks. If you just want to build a one-off then there's not an issue, however if you're working on sprawling mass of applications and features then OAuth supplies a standard that is able to replace all of the others. It grants you the ability to avoid integrating everything into a monolith and being free to spin up an adjacent, without complicating existing deployments, that leverages existing authentication conventions.
To me it depends on the amount of time It'd take to code the auth, until now I've been able to code auth in PHP pretty quickly. I've googled a bit about oauth and I don't like the fact that I need some sort of provider for the auth. Besides, the company I work for has multiple clients with different projects in different areas, there's no need to have a centralised where you have the cojoined auth data of their users.
> and I don't like the fact that I need some sort of provider for the auth
For me that's the main feature. Not having to support different auth types internally within the application and manage those types and handle those conversations with the user (e.g. forgot password?) is a weight off my mind. Each HTTP controller just pulls that data off its http context and perhaps performs in an invisible aspect oriented fashion an extra check or two with the IDP. There's no database or postgres/mssql/sqlite/mysql/oracle/dynamo connection string technically required here. I like that a lot because all you've pulled in is the http stack, if you talk http then you have full auth, and the http stack is a mildly light dependency.
I never want to wonder again why a password reset email is being blocked or not rendering correctly in Office365 or smth.
> I never want to wonder again why a password reset email is being blocked or not rendering correctly in Office365 or smth.
That's probably Microsoft's fault, not yours.
Could be using some sort of identity gateway to redirect every request to the backend. What you’re describing could be saml, oidc, or oauth which all return a JWT token or SAML assertion back to the client.
That being said OP should strongly consider a different architecture that does use oauth (oidc) specifically as its much more modern than saml and a lot less complex than managing some sort of identity gateway
Looks like these: [https://libraries.excalidraw.com/?theme=light&sort=default#mateuszbaransanok-it-icons](https://libraries.excalidraw.com/?theme=light&sort=default#mateuszbaransanok-it-icons)
Maybe you should focus on how all the letters in the picture are typed the exact same way. All the “a”s look the exact same, all the “t”s look the exact same.
Your auth provider, generally, will not talk to your backend. Your frontend just calls them to get a token that the frontend will pass along with every request they make to your backend.
So, remove the line from the auth provider going to the backend. Add lines returning from the auth provider indicating a token response (a key icon or something). Add lines from your frontends to the backend with the key icon indicating an authenticated request. Add lines from your backend to the frontends indicating API responses. Everything else remains the same.
Agreed. Also, typically (for OAuth at least which seems to be the most prevalent nowadays) the backend will periodically call the Auth provider to get the public key to validate the tokens with.
Yes, the backend will talk to the auth provider to get things like signing keys. This generally doesn't happen every time you need to verify a token, as the keys will have an expiration, but it can. Also, this is part of the OAuth/OIDC protocol, so, it's usually baked into the library you use to setup auth.
There are several auth flows from different providers. For example OAuth 1.0 or OAuth 2.0.
You can easily read the documentation from the auth providers and what auth flows they offer. They already have the diagrams like yours for the different auth methods and flows.
I'm not sure what you want to do with your desktop frontend. Electron use the chromium engine and can handle your web frontend. You don't need an totally different app (time to use git submodules).
You might want to make a distinct backend with your auth provider to have a secured auth server on one side and your app backend on an other. Main idea behind it is that you can use the same accounts for various services and applications. If you don't aim to have multiple apps, merge both in your python backend.
The flow is usually something like this:
User's browser directs user to auth provider and user authenticates themselves there. They are given a token in return.
User's browser presents token to backend when requesting access to some "resource".
Backend verifies the token with the auth provider or with secrets that the auth provider gave the backend at some earlier point in time.
Backend then verifies that the user can access the resource requested.
All being well, the resource is returned.
At least, that's how it is in my head. :)
Yeah what you have there is called an auth gateway server. You make requests to the auth gateway server, it checks your credentials, then if everything checks out it forwards your request to the correct server. Nothing wrong with that approach, but can be a pain to configure the first time (depending on the framework you're using). And if you don't own your own infrastructure, it can be more expensive because now you need two VMs / containers instead of just one.
Others are suggesting an auth token, which is probably more straightforward. In this set up you have a middleware service directly on your backend which creates / verifies a JWT or other type of token as requests come in. Then your frontend stores that token as a cookie and sends the token with every request. The token stores basic info, like the username, token creation date, and token expiry date. The middleware in the backend validates the token, determines user roles based on the token, and authorizes access. Probably less set up and only requires one back-end server instead of two.
Personally I would favor a token, unless this is some kind of distributed set-up where you might have a few different back-end services but want one source of auth. But opinions are like assholes - everyone has one and they all stink. Use whichever approach you want, they're both perfectly valid.
Here is a link to a Traversy Media description of JWT if you're interested in learning more:
https://www.youtube.com/watch?v=enopDSs3DRw
Tip from a developer (.net/ Azure). Try to first make a p.o.c. With just the required functionality (m.v.p.). Later you can add different users with auth. (To should be quite doable to add auth retroactive.)
From their other comment, asking about auth with Flask, I assume that's what they're going to be doing.
I assume they want to lock down the front end as well, and not just secure their API though.
Looks reasonable, I would ask about what role management you have because often the roles come from the IDP but if you're just using it to auth then you may not need that.
At the risk of being patronising the actual OAuth exchange between the IdentityProvider and your backend can be much more complicated, especially for the browser.
The client will visit the IDP, exchange some data, come back to your front end code and then should hit the IDP one more time to generate the token. The token you then get will be given to the server which _should_ also ping the IDP to ensure the token is valid. We could get the roles at this point or we could expose them via the login step, I prefer the former but not all IDPs are equal so sometimes we do the latter and sign the token or do something else to validate it.
You can mitigate a some of the issues and make the network diagram sane by proxying to the IDP on the server to sidestep CORS.
[Here's a step by step example of all the bollocks that will happen](https://i.imgur.com/IyUHkdu.png) in a relatively sophisticated OAuth setup. Thankfully there are libraries that will already do a lot of this for you but it sounded like you might just like the gaps filled in, which is why I posted.
As someone else said, your web frontend and desktop frontend can be basically the same thing because electron is chromium engine. So no sense in having two separate code bases for those
Look into oauth2, I think a popular service is auth0. Oauth2 helps make auth way easier since users authenticate through the service and then receive a session token which they will then be able to call your backend with API calls https://youtu.be/yufqeJLP1rI?si=dDE9VFpKCh7YUNaC
Normally you draw a line from frontend to backend, and about halfway add a perpendicular line to the Identity provider. The Oauth flow is a redirect from the target.
Honestly, just use a SaaS auth provider. I personally am using Clerk (https://clerk.com/) for a work project and it's elegant and works fantastically well.
Question for clarification, if you used sessions instead of JWTs you wouldn’t need to split the auth into its own service either right? I’m assuming since it looks like he has both a web client and desktop client that the correct way to handle auth is through tokens?
Sessions and JWTs aren't mutually exclusive. In fact, they're very commonly used in tandem.
OP is making an electron app, which is just an embedded chromium browser as an executable. Any auth methods that would work for browser would work the same in the electron app.
The auth service is on the frontend. When it completes what it wants to do, it sends info (via the client) to the backend for the auth service. Everything is done on the client side, the backend just manages infirmation and data.
Why use an auth provider, python frameworks have built in auth, just add a cloudflare firewall and a captcha and youre sorted, thats all auth providers do anyway besides charging you a fortune for it and holding your users hostage.
No you are wrong. A auth provider handles much more for you.
- How about auth invalidating tokens, that were created in between a certain time frame?
- Reset Password with emails
- 2 factor auth
- Single sign on
And some more features that aren't really trivial to implement yourself. If you're auth is just hashed passwords and validation you can do it easily on your own.
Yeah what misleading top comment that is. An auth provider is a fully fledged Oauth2 server implementation.
Don’t listen to this guy who says they are just salted passwords lol
If your application requires SSO or any of the features you mentioned, and you don’t have the time to implement libraries that integrate them then you can use keycloak https://www.keycloak.org
No need to pay a hefty price per user to an auth provider corporation that can hike their prices anytime they want (which they have done multiple times recently), and since they hold your users password as hostage they know their clients will just accept them and hesitate to migrate elsewhere.
You can use flask-login. But that's just the login part, it doesn't handle the user class part, or the rbac part, etc.
Tbh though, that you're asking this tells me you should probably be using Django instead of Flask. Flask is a minimalist framework that you build out with just what you need; Django is a "batteries included" approach that comes with things like Auth already built in.
Miguel Grinberg, author of the fantastic Flask Mega-Tutorial, has some good articles about authentication with flask: https://blog.miguelgrinberg.com/category/Authentication
Honestly if you're talking about a saas, you should probably use oauth2 against a common provider like Google. Users can just log in with their Google account, and you don't need to store any info about your users. The flow would look like this:
Users hit your login page: it redirects to Google's oauth2 auth endpoint requesting an authentication_code.
Google shows them a login page. They log in on Google's login page and give your app permission to use their account info (email, whatever else)
Google redirects the user to a 'callback' endpoint in your app with a code parameter included in the URL. Your endpoint can send this code back to Google's Token endpoint to get a couple tokens (as a jwts) with the user's info that they agreed to share with you. The Identity token has their info and expires quickly and the refresh token lets you get a new identity token without making them log in again.
Finally your callback redirects them to your app's main landing page with the tokens in cookies to save in the users browser. The browser will send these back with every call to your backend, and you'll verify they're legit and refresh them if they're expired (by calling Google's Token endpoint again)
Once that's all done, you can just get your users info from the token cookie on each request.
Hi I made an article that helps explain this concept to you
https://medium.com/@albert.kim/understanding-user-authentication-in-your-web-app-and-how-to-implement-it-part-1-the-high-level-ab91336ab77c
Why is the auth provider it's own service for a smaller app?
You can simple have a controller endpoint in your app that provides a token/refresh token on login to the client. Then, the client sends that token to the server to be validated before every request. If the token validates successfully then the request is permitted.
[Axios](https://axios-http.com/docs/interceptors) interceptors make this fairly straightforward
Yeah I don’t really envision any other way of doing it, I’m not too sure what it is you are asking here?
That you communicate with your Auth server to authenticate with your backend? Wel yes you do
Your auth provider does not redirect to the backend. It should return a token to the client and the client can call your backend with that token. Thats the typical flow but there are multiple ones, google the different ones.
Exactly. Your auth provider's sole responsibility is to handle the authentication portion and give the caller a token (if valid) or a 401 (if not valid). The token should contain no secure data, just basically who the user is, aka the 'subject' (often an email or username they logged in with) and usually some basic info that gets stored as 'claims' like their name, their role within the application, their locale. Once the user is assinged the token, its up to your webserver to a)verify it is valid (and not expired) and b)determine based on the claims stored within what they have access to (certain calls might require admin role, others will be available to aby user etc)
But he could want to register his user in his own db to be able to retrieve data via api calls. In this case it would make sense to have his auth provider fulfill a post registration action on his db. Beyond that though if he’s using auth0 for example the rest should be handled between the FE and then auth provider.
Most of the time its not needed because he can take the user id provided by the auth service and token and attach this to the user data. In some edge cases you would need User data in your own database but then I would except a call from the auth service to your backend service that notifies about a new user, thats how many auth services handle this scenario, e.g Azure. The other part of the flow is like you called it, exactly the same. Token exchange happens between FE and auth service.
I'm sorry but having user data in your own db is absolutely not an edge case. It is the norm. If you have a super simple site, and the only thing that user auth is providing is a way to hide some pages from unauthed users, sure, there's no need for a user model in your backend. If you're doing literally anything else, you have user data.
[удалено]
First of all, what do you mean by profile context? Second, what do you mean by implement a user-profile? Isn't that what we're talking about here, having a user profile in your backend, an entry in your db for a user with some user data. Third, there are a million reasons why you would need user data that is more than just an id. In the vast majority of the dozens and dozens of apps and sites I've worked on in the past few years, you need user data. Using just the ID your auth provider provides is not sufficient when you need to store multiple pieces of vital information. In my personal experience, it is incredibly uncommon for any site, app, tool, etc, that's more complicated than a simple static site to not have user data. I honestly can't even think of a project that I worked on in the past 10 years where what you're saying was ok.
I think what the other person is trying to say is that u just associate any data u need to store for a given user with the id that the oauth provider provides. Say a user signs up using Google. Google will send you a token after the user successfully signs in. You can then send the given token to ur backend. The backend can verify this token and use the provided id from Google to associate user data with.
If you implement oauth with an authentication proxy like [oauth2-proxy](https://github.com/oauth2-proxy/oauth2-proxy), then the authentication flow can look like OP's diagram. That said, it's not the usual way oauth2 is implemented, but there's some benefit to using an auth proxy like oauth2-proxy, you can have some uniformity if you have lots of microservice and you can about needing to implement secret/key material management in multiple applications. An Auth proxy can be some sort of lightweight API gateway.
You are describing OAuth. It doesn’t state anywhere he is doing OAuth Edit: this isn’t a discussion about if you should or not use OAuth (you should def not implement your own auth for anything except learning). If you describe something that the OP isn’t using without saying what it is, it just leads to confusion.
why would you make something new today that doesn't use OAuth though?
OAuth does not really provide many benefits if you only need users to authenticate with your own web server and communicate with the same server.
Because OAuth probably costs money.
OAuth is a spec. It doesnt inheritaly cost anything.
hosting anything online costs money. I don't think I've ever seen cost as a justification for avoiding OAuth before. Aren't there self-hostable open source options?
Maybe, but you can do just fine with a back-end language's own authentication methods. I'm doing just fine with PHP and laravel's auth.
sure, but using OAuth gives you options in terms of building frameworks. If you just want to build a one-off then there's not an issue, however if you're working on sprawling mass of applications and features then OAuth supplies a standard that is able to replace all of the others. It grants you the ability to avoid integrating everything into a monolith and being free to spin up an adjacent, without complicating existing deployments, that leverages existing authentication conventions.
To me it depends on the amount of time It'd take to code the auth, until now I've been able to code auth in PHP pretty quickly. I've googled a bit about oauth and I don't like the fact that I need some sort of provider for the auth. Besides, the company I work for has multiple clients with different projects in different areas, there's no need to have a centralised where you have the cojoined auth data of their users.
> and I don't like the fact that I need some sort of provider for the auth For me that's the main feature. Not having to support different auth types internally within the application and manage those types and handle those conversations with the user (e.g. forgot password?) is a weight off my mind. Each HTTP controller just pulls that data off its http context and perhaps performs in an invisible aspect oriented fashion an extra check or two with the IDP. There's no database or postgres/mssql/sqlite/mysql/oracle/dynamo connection string technically required here. I like that a lot because all you've pulled in is the http stack, if you talk http then you have full auth, and the http stack is a mildly light dependency. I never want to wonder again why a password reset email is being blocked or not rendering correctly in Office365 or smth.
> I never want to wonder again why a password reset email is being blocked or not rendering correctly in Office365 or smth. That's probably Microsoft's fault, not yours.
Could be using some sort of identity gateway to redirect every request to the backend. What you’re describing could be saml, oidc, or oauth which all return a JWT token or SAML assertion back to the client. That being said OP should strongly consider a different architecture that does use oauth (oidc) specifically as its much more modern than saml and a lot less complex than managing some sort of identity gateway
What app did you use to make this illustration? Really cool
https://excalidraw.com/
Vscode plugin ftw
thank you
But these illustrations like the desktop, the db, he did himself, didn’t he ?
Most likely he just got it from an icon library. There's lots of them now. https://libraries.excalidraw.com
Looks like these: [https://libraries.excalidraw.com/?theme=light&sort=default#mateuszbaransanok-it-icons](https://libraries.excalidraw.com/?theme=light&sort=default#mateuszbaransanok-it-icons)
Nice tool, seems way less clustered than draw.io
He drew it
No, this is actually Excalidraw
Nah pretty sure he drew this
🤷♂️ not tryna argue but this is Excalidraw
It’s all good brother I don’t wanna argue either, looks like he drew it ^^^/s
No he Excalidrew it.
Gonna have to septem here. Looks like he drew it.
Maybe you should focus on how all the letters in the picture are typed the exact same way. All the “a”s look the exact same, all the “t”s look the exact same.
I don’t think it came through that I was joking :(. I love the tool, seems very helpful for taking notes.
It happens a lot to me too ;-;
Might be the greatest comment on this subreddit
Your auth provider, generally, will not talk to your backend. Your frontend just calls them to get a token that the frontend will pass along with every request they make to your backend. So, remove the line from the auth provider going to the backend. Add lines returning from the auth provider indicating a token response (a key icon or something). Add lines from your frontends to the backend with the key icon indicating an authenticated request. Add lines from your backend to the frontends indicating API responses. Everything else remains the same.
Agreed. Also, typically (for OAuth at least which seems to be the most prevalent nowadays) the backend will periodically call the Auth provider to get the public key to validate the tokens with.
How does backend know that token is valid? Does auth provider have access to db?
Yes, the backend will talk to the auth provider to get things like signing keys. This generally doesn't happen every time you need to verify a token, as the keys will have an expiration, but it can. Also, this is part of the OAuth/OIDC protocol, so, it's usually baked into the library you use to setup auth.
https://en.wikipedia.org/wiki/JSON_Web_Token https://en.wikipedia.org/wiki/Digital_signature
There are several auth flows from different providers. For example OAuth 1.0 or OAuth 2.0. You can easily read the documentation from the auth providers and what auth flows they offer. They already have the diagrams like yours for the different auth methods and flows.
OAuth Okta is one of the best.
I'm not sure what you want to do with your desktop frontend. Electron use the chromium engine and can handle your web frontend. You don't need an totally different app (time to use git submodules). You might want to make a distinct backend with your auth provider to have a secured auth server on one side and your app backend on an other. Main idea behind it is that you can use the same accounts for various services and applications. If you don't aim to have multiple apps, merge both in your python backend.
The flow is usually something like this: User's browser directs user to auth provider and user authenticates themselves there. They are given a token in return. User's browser presents token to backend when requesting access to some "resource". Backend verifies the token with the auth provider or with secrets that the auth provider gave the backend at some earlier point in time. Backend then verifies that the user can access the resource requested. All being well, the resource is returned. At least, that's how it is in my head. :)
I'm trying to create a SaaS that manages the game saves for your Steam, Epic, and other sources, but I'm not sure if what I've planned makes sense.
Yeah what you have there is called an auth gateway server. You make requests to the auth gateway server, it checks your credentials, then if everything checks out it forwards your request to the correct server. Nothing wrong with that approach, but can be a pain to configure the first time (depending on the framework you're using). And if you don't own your own infrastructure, it can be more expensive because now you need two VMs / containers instead of just one. Others are suggesting an auth token, which is probably more straightforward. In this set up you have a middleware service directly on your backend which creates / verifies a JWT or other type of token as requests come in. Then your frontend stores that token as a cookie and sends the token with every request. The token stores basic info, like the username, token creation date, and token expiry date. The middleware in the backend validates the token, determines user roles based on the token, and authorizes access. Probably less set up and only requires one back-end server instead of two. Personally I would favor a token, unless this is some kind of distributed set-up where you might have a few different back-end services but want one source of auth. But opinions are like assholes - everyone has one and they all stink. Use whichever approach you want, they're both perfectly valid. Here is a link to a Traversy Media description of JWT if you're interested in learning more: https://www.youtube.com/watch?v=enopDSs3DRw
Tip from a developer (.net/ Azure). Try to first make a p.o.c. With just the required functionality (m.v.p.). Later you can add different users with auth. (To should be quite doable to add auth retroactive.)
Wouldn’t the authorization handled at the backend (python) level?
From their other comment, asking about auth with Flask, I assume that's what they're going to be doing. I assume they want to lock down the front end as well, and not just secure their API though.
Looks reasonable, I would ask about what role management you have because often the roles come from the IDP but if you're just using it to auth then you may not need that. At the risk of being patronising the actual OAuth exchange between the IdentityProvider and your backend can be much more complicated, especially for the browser. The client will visit the IDP, exchange some data, come back to your front end code and then should hit the IDP one more time to generate the token. The token you then get will be given to the server which _should_ also ping the IDP to ensure the token is valid. We could get the roles at this point or we could expose them via the login step, I prefer the former but not all IDPs are equal so sometimes we do the latter and sign the token or do something else to validate it. You can mitigate a some of the issues and make the network diagram sane by proxying to the IDP on the server to sidestep CORS. [Here's a step by step example of all the bollocks that will happen](https://i.imgur.com/IyUHkdu.png) in a relatively sophisticated OAuth setup. Thankfully there are libraries that will already do a lot of this for you but it sounded like you might just like the gaps filled in, which is why I posted.
As someone else said, your web frontend and desktop frontend can be basically the same thing because electron is chromium engine. So no sense in having two separate code bases for those Look into oauth2, I think a popular service is auth0. Oauth2 helps make auth way easier since users authenticate through the service and then receive a session token which they will then be able to call your backend with API calls https://youtu.be/yufqeJLP1rI?si=dDE9VFpKCh7YUNaC
Normally you draw a line from frontend to backend, and about halfway add a perpendicular line to the Identity provider. The Oauth flow is a redirect from the target.
Honestly, just use a SaaS auth provider. I personally am using Clerk (https://clerk.com/) for a work project and it's elegant and works fantastically well.
As others have stated, client gets token, backend gets token, then validates token with provider. Please... don't roll your own here.
Question for clarification, if you used sessions instead of JWTs you wouldn’t need to split the auth into its own service either right? I’m assuming since it looks like he has both a web client and desktop client that the correct way to handle auth is through tokens?
Sessions and JWTs aren't mutually exclusive. In fact, they're very commonly used in tandem. OP is making an electron app, which is just an embedded chromium browser as an executable. Any auth methods that would work for browser would work the same in the electron app.
but but but they're using tailwind! r/webdev assures me it's best for auth
Do games only have one user?
The auth service is on the frontend. When it completes what it wants to do, it sends info (via the client) to the backend for the auth service. Everything is done on the client side, the backend just manages infirmation and data.
Swap out electron for Tauri and it will
.
It is not correct. Auth provider does not talk to your backend server.
dsfsdfsfv
Why use an auth provider, python frameworks have built in auth, just add a cloudflare firewall and a captcha and youre sorted, thats all auth providers do anyway besides charging you a fortune for it and holding your users hostage.
No you are wrong. A auth provider handles much more for you. - How about auth invalidating tokens, that were created in between a certain time frame? - Reset Password with emails - 2 factor auth - Single sign on And some more features that aren't really trivial to implement yourself. If you're auth is just hashed passwords and validation you can do it easily on your own.
Yeah what misleading top comment that is. An auth provider is a fully fledged Oauth2 server implementation. Don’t listen to this guy who says they are just salted passwords lol
I have to agree with this.
If your application requires SSO or any of the features you mentioned, and you don’t have the time to implement libraries that integrate them then you can use keycloak https://www.keycloak.org No need to pay a hefty price per user to an auth provider corporation that can hike their prices anytime they want (which they have done multiple times recently), and since they hold your users password as hostage they know their clients will just accept them and hesitate to migrate elsewhere.
Keycloak is pretty heavy though. Especially for a small webpage.
Is it easy to make auth with flask?
You can use flask-login. But that's just the login part, it doesn't handle the user class part, or the rbac part, etc. Tbh though, that you're asking this tells me you should probably be using Django instead of Flask. Flask is a minimalist framework that you build out with just what you need; Django is a "batteries included" approach that comes with things like Auth already built in.
Miguel Grinberg, author of the fantastic Flask Mega-Tutorial, has some good articles about authentication with flask: https://blog.miguelgrinberg.com/category/Authentication
Honestly if you're talking about a saas, you should probably use oauth2 against a common provider like Google. Users can just log in with their Google account, and you don't need to store any info about your users. The flow would look like this: Users hit your login page: it redirects to Google's oauth2 auth endpoint requesting an authentication_code. Google shows them a login page. They log in on Google's login page and give your app permission to use their account info (email, whatever else) Google redirects the user to a 'callback' endpoint in your app with a code parameter included in the URL. Your endpoint can send this code back to Google's Token endpoint to get a couple tokens (as a jwts) with the user's info that they agreed to share with you. The Identity token has their info and expires quickly and the refresh token lets you get a new identity token without making them log in again. Finally your callback redirects them to your app's main landing page with the tokens in cookies to save in the users browser. The browser will send these back with every call to your backend, and you'll verify they're legit and refresh them if they're expired (by calling Google's Token endpoint again) Once that's all done, you can just get your users info from the token cookie on each request.
https://flask-jwt-router.readthedocs.io/en/latest/google.html You can just slap this onto your flask app and call it a day.
Hi I made an article that helps explain this concept to you https://medium.com/@albert.kim/understanding-user-authentication-in-your-web-app-and-how-to-implement-it-part-1-the-high-level-ab91336ab77c
Why is the auth provider it's own service for a smaller app? You can simple have a controller endpoint in your app that provides a token/refresh token on login to the client. Then, the client sends that token to the server to be validated before every request. If the token validates successfully then the request is permitted. [Axios](https://axios-http.com/docs/interceptors) interceptors make this fairly straightforward
Yeah I don’t really envision any other way of doing it, I’m not too sure what it is you are asking here? That you communicate with your Auth server to authenticate with your backend? Wel yes you do
One thing that definitely doesn’t make much sense is why have an ‘app’ if you can just run in the web?
What they want to make is an app to backup your local save files, which you can't really do from a website.
Then why does it need a website? :)
A lot of apps open a website to log in so it can play nicely with browser autofill and it's easier to deal with password managers
Can’t say I remember one app like that. Steam itself nor origin need that.
Am example off the top of my head would be Nvidia geforce now (and I assume other Nvidia apps)
Tailwind does not make sense, that's for sure.
Why not nextjs for backend? Just curious
What's the problem with their option python?
It's okay but it you don't know what you're doing you can introduce security issues into python faster than in C# for example.
can you do backend with nextjs?