Do we have to enforce the same origin policy on android/iOs applications?

[mr-super-thiccc]

I’m building an android application using this wrapper.
The authorization guide for the web API states that one has to protect against CSRF by properly implementing a state parameter and abide by the same origin policy.

My issue is that I'm having a bit of trouble wrapping my head around how to properly implement the same origin policy using authorization code flow and this wrapper.

For my app, I’m using this wrapper and a variation of the server script written in node.js that is provided in the web API tutorial.
The original script can be found here: https://github.com/spotify/web-api-auth-examples/blob/master/authorization_code/app.js

There are two main differences between my server script and the original server script.

1.) The original server script concerns itself with just the web API and isn’t really intended for use in conjunction with a mobile application.
2.) As such, the only notable difference is I don’t implement a /login route on my server, because I delegate making the initial GET request to accounts.spotify.com/authorize to an AuthenticationRequest.Builder object and the LoginActivity.

My primary concern stems from the fact that I delegate redirection to accounts.spotify.com/authorize using an AuthenticationRequest.Builder object.

My authentication process is as follows:

//Start authentication process

1.) A GET request is made to accounts.spotify.com/authorize with a client_id, response_type, REDIRECT_URI, scope, parameters, and most importantly, a state parameter.

I think my application makes this request with an AuthenticationRequest.Builder object.

I construct this object with the following values:
final AuthenticationRequest request = new AuthenticationRequest.Builder(CLIENT_ID, AuthenticationResponse.Type.CODE, REDIRECT_URI)
.setScopes(new String[]{“user-top-read playlist-read"})
.setState(randomGenHash)
.build();

randomGenHash is a randomly generated hash created on my app that I pass into the .setState argument.

2.) The AuthenticationClient.openLoginActivity() opens up the login activity where users log into Spotify using the provided login activity. Once the user logs in, the activity displays the requested scopes and asks the user to authorize the scopes or not.

3.) If the user allows access to all of the provided scopes (let’’s say they do), a response is given back to my application, with response.getType() == CODE.
The response contains an authorization code and a state parameter if I passed one (in this case, the state parameter should be randomGenHash).

4.) My app then makes a GET request to my REDIRECT_URI passed in to the AuthenticationRequest.Builder object in 1.) using Volley, with the authorization code being sent as a parameter.

5.) The authorization code is exchanged for an access and refresh token.

6.) Access and refresh tokens are sent back to my application.

//End authentication process

My question and main concern is this:

From my understanding of the original script, a cookie is made on our server when the /login route is called.

The /login route redirects and makes a GET request to accounts.spotify.com/authorize and send the cookie and state along with it.

If the user allows access to the scopes after they’ve logged in, accounts.spotify.com/authorize redirects back to our /callback route.

When our /callback route is called, our server checks if the state parameter is a valid value in the cookie (to ensure it’s coming from the same origin). /this is my issue/

If the state is in the cookie, then we’re fairly certain the request came from the same domain and the authorization code is exchanged for access and refresh tokens.

Now, let’s say my node.js server script is hosted on somedomain.com, with somedomain.com/callback as my REDIRECT_URI passed as the REDIRECT_URI argument in 1.).

On my application, no such state parameter checking takes places, because my server doesn’t get to look at the state parameter (randGenHash) until redirection passes through the /callback route on my server from account.spotify.com/authorize.

Thus, I don’t think this my application protects against CSRF at all.

Is it necessary to enforce the same origin policy (I’m almost positive it is), and if so, can anyone help point me in the right direction of how I would go about enforcing the same origin policy on my application?

I’ve been trying to figure this issue out for quite some time now and I haven’t figured out how to enforce the same origin policy if I delegate the accounts.spotify.com redirection to a AuthenticationRequest.Builder object

I would immensely appreciate any and all help.