<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Understanding Long Term Authorization in Spotify for Developers</title>
    <link>https://community.spotify.com/t5/Spotify-for-Developers/Understanding-Long-Term-Authorization/m-p/6179839#M14387</link>
    <description>&lt;P&gt;Even if in your code you reference an environment variable, that only protects an API key from bad actors snooping through repositories on GitHub. Any build process for React or purely front-end Next.js will ultimately stick that API key into the JavaScript bundle shipped to the client, and it'll be exposed. Think about it: the only way users will be able to use your API key from a purely front-end app is if its in front end code&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;However, Next.js allows for a lot of server-side actions... and, for your use case, caching behavior. You could get away with simple API key usage with some specific Next.js caching config. And deploying Next.js to Vercel is pretty streamlined. The free tier for hosting is generous, but if you're looking to monetize your app, that's a different story&lt;/P&gt;</description>
    <pubDate>Sun, 07 Jul 2024 20:21:49 GMT</pubDate>
    <dc:creator>smacklol</dc:creator>
    <dc:date>2024-07-07T20:21:49Z</dc:date>
    <item>
      <title>Understanding Long Term Authorization</title>
      <link>https://community.spotify.com/t5/Spotify-for-Developers/Understanding-Long-Term-Authorization/m-p/6158324#M14285</link>
      <description>&lt;P&gt;&lt;STRONG&gt;Plan&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Free/Premium&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Country&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Device&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;(iPhone 8, Samsung Galaxy 9, Macbook Pro late 2016)&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Operating System&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;(iOS 10, Android&amp;nbsp;Oreo, Windows 10,etc.)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;My Question or Issue&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Hi, I'm developing a front end React Application where the&amp;nbsp;&lt;EM&gt;only&lt;/EM&gt; things I want from the API are just a few specific playlists and some recommendations. I don't need/want users to sign in, and ideally only I need to sign in once and then it'll remain authorized. I can't use a back end server, which seems required for refresh tokens. Is that correct? What would be the best way to go about this&lt;/P&gt;</description>
      <pubDate>Wed, 26 Jun 2024 17:15:39 GMT</pubDate>
      <guid>https://community.spotify.com/t5/Spotify-for-Developers/Understanding-Long-Term-Authorization/m-p/6158324#M14285</guid>
      <dc:creator>Blyxie</dc:creator>
      <dc:date>2024-06-26T17:15:39Z</dc:date>
    </item>
    <item>
      <title>Re: Understanding Long Term Authorization</title>
      <link>https://community.spotify.com/t5/Spotify-for-Developers/Understanding-Long-Term-Authorization/m-p/6159787#M14292</link>
      <description>&lt;P&gt;If you do not have a backend, then you need to get a token via &lt;A href="https://developer.spotify.com/documentation/web-api/tutorials/code-pkce-flow" target="_blank"&gt;authorization&lt;/A&gt; (user login). If you maintain a backend, then you can use &lt;A href="https://developer.spotify.com/documentation/web-api/tutorials/client-credentials-flow" target="_self"&gt;client credentials&lt;/A&gt; (no user login required).&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;What kind of application are you developing? Maybe you have a need of a backend for some other feature in the application?&lt;/P&gt;</description>
      <pubDate>Thu, 27 Jun 2024 08:45:16 GMT</pubDate>
      <guid>https://community.spotify.com/t5/Spotify-for-Developers/Understanding-Long-Term-Authorization/m-p/6159787#M14292</guid>
      <dc:creator>LambertSpot</dc:creator>
      <dc:date>2024-06-27T08:45:16Z</dc:date>
    </item>
    <item>
      <title>Re: Understanding Long Term Authorization</title>
      <link>https://community.spotify.com/t5/Spotify-for-Developers/Understanding-Long-Term-Authorization/m-p/6160164#M14299</link>
      <description>&lt;P&gt;It's more that I don't want to pay for a server to deploy the application, although I could use something like NextJS maybe and host that for free on Vercel? However, if the client secret was kept as an env variable, couldn't that hide it even in a front end?&lt;/P&gt;</description>
      <pubDate>Thu, 27 Jun 2024 13:01:45 GMT</pubDate>
      <guid>https://community.spotify.com/t5/Spotify-for-Developers/Understanding-Long-Term-Authorization/m-p/6160164#M14299</guid>
      <dc:creator>Blyxie</dc:creator>
      <dc:date>2024-06-27T13:01:45Z</dc:date>
    </item>
    <item>
      <title>Re: Understanding Long Term Authorization</title>
      <link>https://community.spotify.com/t5/Spotify-for-Developers/Understanding-Long-Term-Authorization/m-p/6167078#M14326</link>
      <description>&lt;P&gt;Yes, there are several alternatives (Vercel, GCP, AWS, Azure, etc.) that could provide you with a free backend if your usage is low enough (tip is to configure spending limits / alerts to prevent you from getting a surprise invoice).&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;As for why you should not keep API secrets in the front end code, you can find &lt;A href="https://escape.tech/blog/how-to-secure-api-secret-keys/#:~:text=Such%20a%20practice%20makes%20your,found%20in%20a%20JavaScript%20file." target="_self"&gt;several resources online&lt;/A&gt; about the topic. But basically anyone using your application could get a hold of it, and use it to make API requests using your quota, cost you money, or access data related to requests made using it.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Alternatively you can have a user authorization flow, you can read more about it &lt;A href="https://developer.spotify.com/documentation/web-api/tutorials/code-pkce-flow" target="_blank"&gt;here&lt;/A&gt;. But then you need a user to login to query the API.&lt;/P&gt;</description>
      <pubDate>Mon, 01 Jul 2024 09:10:55 GMT</pubDate>
      <guid>https://community.spotify.com/t5/Spotify-for-Developers/Understanding-Long-Term-Authorization/m-p/6167078#M14326</guid>
      <dc:creator>LambertSpot</dc:creator>
      <dc:date>2024-07-01T09:10:55Z</dc:date>
    </item>
    <item>
      <title>Re: Understanding Long Term Authorization</title>
      <link>https://community.spotify.com/t5/Spotify-for-Developers/Understanding-Long-Term-Authorization/m-p/6179839#M14387</link>
      <description>&lt;P&gt;Even if in your code you reference an environment variable, that only protects an API key from bad actors snooping through repositories on GitHub. Any build process for React or purely front-end Next.js will ultimately stick that API key into the JavaScript bundle shipped to the client, and it'll be exposed. Think about it: the only way users will be able to use your API key from a purely front-end app is if its in front end code&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;However, Next.js allows for a lot of server-side actions... and, for your use case, caching behavior. You could get away with simple API key usage with some specific Next.js caching config. And deploying Next.js to Vercel is pretty streamlined. The free tier for hosting is generous, but if you're looking to monetize your app, that's a different story&lt;/P&gt;</description>
      <pubDate>Sun, 07 Jul 2024 20:21:49 GMT</pubDate>
      <guid>https://community.spotify.com/t5/Spotify-for-Developers/Understanding-Long-Term-Authorization/m-p/6179839#M14387</guid>
      <dc:creator>smacklol</dc:creator>
      <dc:date>2024-07-07T20:21:49Z</dc:date>
    </item>
  </channel>
</rss>

