I am trying to create a small app that will use the Spotify API. Because it's meant to be small I don't really want to add any authentication on my end but I still would like to have "sessions".
My current ideia was to, after the OAuth2.0 Authorization Code Flow is done with Spotify, simply store the userID alongside the access and refresh token and use cookie sessions (encrypted) with said userID. However this feels kind of funny, isn't this misusing OAuth2.0? It seems I am trying to use OAuth2.0 for auth, kind of like OIDC. Is this approach acceptable or is there a better way of handling this?
I was also wondering how could I use the "state" parameter if I don't really have performed any authentication before the flow is completed. Should I also be creating a session before the user enters the OAuth2.0 flow and checking it at the end? I think I might also be misunderstanding the "state" parameter usefulness.
Delegating authentication to some external OAuth2 server is a pretty good use-case for OAuth2, and often done. OIDC is overkill for many use-cases, it's just heavily pushed by IdPs.
Without OIDC it means you just need alternative ways to find out a inuqe user id, and it sounds like you have this. It's a good idea to keep the flow on the server (which it sounds like you have) and roll your own session ids. You don't need to encrypt anything if you use a session system.
The 'state' parameter lets you ensure that the redirect back from the authorization endpoint is actually done by Spotify. You can put a random string in there and validate it after. Some people also stuff other information in there, which may be useful in stateless systems (but it doesn't sound like you have a stateless system).
If Spotify supports it, it's better to use PKCE, and when you do you can forget about the state parameter.