In essence, you are using your login system to accomplish two separate goals:
- Authenticate regular users
- Give guest users access to otherwise authenticated pages
As a general rule of thumb using one thing for two purposes tends to cause its own problems in the long run, and so if nothing else the SRP suggests this is a bad idea. There are certainly plenty of ways this can cause problems:
- You'll still need access controls to make sure that users of this guest account aren't granted access to other API endpoints that are not supposed to be accessible to them. This, in fact, would probably be my biggest concern: when writing a new API endpoint it would be very easy to forget "Hey, we have guest users that use this other special login" and therefore forget to prevent access to a new API to said guest users. If that API happens to deal with sensitive information, then you may effectively end up with a public and critical data breach.
- By allowing many users to share one account, you make auditing and data access logs much trickier to implement effectively.
- If you ever need to change the credentials for the guest account you can't do so without logging out all active guest users
There are two alternate routes you could take:
1. Separate endpoints that don't require login
This has plenty of advantages. Granted, you do have to create a separate set of endpoints, but it will add a layer between your unauthorized users and your authorized systems. This both makes it harder for them to potentially find security weaknesses (since they are limited to a much smaller subset of your system) and also makes it harder for your developers to make mistake. When there is clear separation between, e.g. "This code is for authorized users" and "This code is for unauthorized users" then it is harder for someone to forget what part they are working on and make a security blunder as a result (note that I said harder - not impossible). This is will make it easier to properly secure your endpoints, even if you can't precisely quantify the end result.
2. Separate guest accounts for each user with restricted access controls
There isn't a ton of background in your question, but based on what little I can see this probably won't make sense for you. Still I figured it never hurts to mention things. Another option is to simply create a separate guest account for each "guest" user of your system. This works best if your system already has clear access controls in place (so you can confidently lock such users out of places they aren't supposed to be) or if used in conjunction with a separate set of API endpoints (i.e. guest users are automatically locked out of all endpoints except these public ones).
You end up with a bit more code to manage this way (as opposed to just having some completely open endpoints) but it has some advantages:
- You can more cleanly track guest users in your system, presuming that you are already tracking your users based on their logins
- If you have a concept of "converting" these guest users into full users of your system, you'll already have the process half done when it comes time for conversion, and then you will be able to easily track a user's history from before they even "officially" signed up.
- Depending on how a user becomes one of these guest accounts, your "public" endpoints don't have to actually be fully wide-open. I.e. if a user clicks a button to "Accept terms and conditions" and then is automatically becomes a guest user, and you have to be a guest user to access these "public" pages, then you will have effectively kicked out most bots and automated scraping systems from your endpoints.