SpotifyWebAPI rewrite/redesign

This issue covers the following change: Rewrite and Redesign of our Auth-Services and HTTP-Requests for the Spotify Web-API

Auth Services Web-API

Before I go into detail, I will quickly explain how each Auth-Service is working, you can find detailed infos at their Web-API docs.

• Credentials-Auth
• ImplicitGrant-Auth
• AuthorizationCode-Auth

Credentials-Auth

This one is fairly easy, it uses both, clientId and clientSecret and you just need to make a call to spotify with both values and you will receive your token. You can’t access account data with it, so there is no user-action involved. This one would be suited for pure server-side applications while no access to user-data is needed. In the following I will ignore this Auth-Service, since it can be achieved with pure HTTP-Requests, no server required.

ImplicitGrant-Auth

This Auth-Service is short lived and requires user-action but will also give you access to account-data. It was designed for use on sites like jsfiddle, where you have no direct HTTP-Server and only have access to some Client JS code. The token will be passed as a hash-fragment in your return url. So, technically, the HTTP-Server can’t fetch this token since hash-fragments are a browser concept and are not send over the wire. You could write some client-js, fetch the token, and redirect with the token as query-parameter. But this is hacky. Also, this would require adding localhost:XXXX to your allowed redirect URLs inside spotify (like we currently have to do it) --> Anyone can create tokens based on your clientId. This currently is the case.

AuthorizationCode-Auth

This is the perfect Auth-Service for servers. This also uses clientId and clientSecret, so this is also just a server-side Auth-Service. It requires user-action, gives access to account-data and provides a refresh token. This refresh token can be used to get a new token without having the user to login again. After the user granted access, he will be redirected to an URL where the token is passed via parameter --> perfect for an HTTP-Server.

Ideas for the redesign/rewrite

• Patch Credentials-Auth: Make it cross-platform using HttpClient
• Delete ImplicitGrant-Auth: It’s not secure enough
• Major AuthorizationCode-Auth: This should be our main focus, more below
• Patch SpotifyWebAPI: Cross-Platform, replace WebClient with HttpClient

Cross-Platform

We should make the whole Web-API cross-platform so we can run this shit on linux servers and actually use those auth methods correctly 😛.

This would require following changes:

• Replace WebClient with HttpClient (HttpClient doesn’t provide sync methods, we need some workaround)
• Rewrite the HTTP-Server (more below)

HTTP-Server

The HTTP-Server currently is mostly messy due to the fact I took it from stackoverflow or something similar and just edited it. It will only be used for AuthorizationCode-Auth. We need to provide enough configuration like ports, bind to specific IP-Adresses, and my favorite feature: custom HTML. Currently, a rather simple message shows that authentication was successful. It would be nice to support injecting custom HTML into the response, or, even better, a custom redirect once everything is authed. The whole API is still to design, we can either go for async-methods or events like we did before.

Regarding AuthorizationCode-Auth: We need to abstract the actual auth process in two types:

• Standalone HTTP-Server:
  This will use the HTTP-Server above. It’s useful when you don’t need any further HTTP stuff. You just need it once and only for authenticating.
• Custom Handler:
  Let’s say we already have an ASP.NET app running. It would be stupid to start another HTTP-Server. Better: Due to the abstraction, we can implement our own strategy. We could define our own route within ASP.NET, fetch the token, and call our strategy callback.

I though of something like the following:

• An interface AuthorizationCodeStrategy
• A class AuthorizationCodeAuth which has one AuthorizationCodeStrategy
• A class AuthorizationCodeServer which implements AuthorizationCodeStrategy and handles a HTTP-Server internally

This way, everyone can make their own strategy without us having to add a dependecy to some large framework. We could even provide strategies in some other repo with specific dependecies.

A lot of text, I hope you have some input 👍
This is just the first step, if we have worked out the design-idea, we will go into details and API-design, so don’t get started yet ⌛ @erinxocon @petrroll @JimmyAppelt

[fotiDim]

Please ignore what I wrote above about await. It was a dummy mistake of mine. With await, Android works as well🤠. However it is odd why .Result does not work.🤔

What about “SpotifyAPI.Web.Auth”? Is it deprecated?

I have updated my project to reflect the changes.

[JohnnyCrazy]

Most of the stuff has been implemented

see #276 for more infos