So I am reluctant to ask too much of a noob question, as this guy aked about a non-standard approach and got down voted a bunch, but here goes.

I am creating a mobile application which needs to interact on a per-user basis with an API. Having worked on several projects as a client of third-party APIs my initial thought was to go with OAuth. However, I have been thinking about it, and I don't plan to open the API up publicly to other consumers - the only consumer will always only be my mobile app, so was thinking if OAuth is actually the best fit? Or is it overkill?

I then read this article advising on a process from Google, which suggests the following approach for exactly this scenario:

• Embed a webview in your app with a normal web based login form
• on successful login, pass secure cookie to mobile app which has secure token
• use token in future api requests

(assuming all over https etc)

This seems a lot simpler than any OAuth implementation, and could quite easily bee done using Spring Security Filter/authentication chain(My server side code is Java & Spring MVC/Secutiry etc). It seems interesting that is the recommended approach from Google, which to my mind has added some credibility to the solution.

Assuming with the above solution I also included a mobile app key etc (just to stop any mobile hitting the form/API), it seems like it would have the same problem as OAuth in as much that I have to include my app key embedded in the mobile code (that could be decompiled etc).

I also read this article about the Amazon approach (Apparently similar to an OAuth 1 impl), which seems like it could be a reasonable extension to the google proposed solution above and rather than send the token to the server, use it as the key to hash the request data.

I am pretty new to implementing anything in security beyond normal web based user/password security - so would appreciate thoughts on when to use OAuth for mobile apps and if the above two solutions (amazon & google) are fit for purpose of if they have been superceded by oauth2.

I am creating a mobile application which needs to interact on a per-user basis with an API. Having worked on several projects as a client of third-party APIs, my initial thought was to go with OAuth. However, I have been thinking about it, and I don't plan to open the API up publicly to other consumers - the only consumer will always only be my mobile app, so was thinking if OAuth is actually the best fit? Or is it overkill?

I then read this article advising on a process from Google, which suggests the following approach for exactly this scenario:

• Embed a webview in your app with a normal web based login form
• on successful login, pass secure cookie to mobile app which has secure token
• use token in future API requests

(assuming all over https etc)

This seems a lot simpler than any OAuth implementation, and could quite easily be done using Spring Security Filter/authentication chain  (My server side code is Java & Spring MVC/Secutiry etc). It seems interesting that is the recommended approach from Google, which to my mind has added some credibility to the solution.

Assuming with the above solution I also included a mobile app key etc (just to stop any mobile hitting the form/API), it seems like it would have the same problem as OAuth in as much that I have to include my app key embedded in the mobile code (that could be decompiled etc).

I also read this article about the Amazon approach (apparently similar to an OAuth 1 implementation), which seems like it could be a reasonable extension to the google proposed solution above and rather than send the token to the server, use it as the key to hash the request data.

I am pretty new to implementing anything in security beyond normal web based user/password security - so would appreciate thoughts on when to use OAuth for mobile apps and if the above two solutions (amazon & google) are fit for purpose of if they have been superseded by OAuth 2.

So I am reluctant to ask too much of a noob question, as this guy aked about a non-standard approach and got down voted a bunch, but here goes.

I am creating a mobile application which needs to interact on a per-user basis with an API. Having worked on several projects as a client of third-party APIs my initial thought was to go with OAuth. However, I have been thinking about it, and I don't plan to open the API up publicly to other consumers - the only consumer will always only be my mobile app, so was thinking if OAuth is actually the best fit? Or is it overkill?

I then read this article advising on a process from Google, which suggests the following approach for exactly this scenario:

• Embed a webview in your app with a normal web based login form
• on successful login, pass secure cookie to mobile app which has secure token
• use token in future api requests

(assuming all over https etc)

This seems a lot simpler than any OAuth implementation, and could quite easily bee done using Spring Security Filter/authentication chain(My server side code is Java & Spring MVC/Secutiry etc). It seems interesting that is the recommended approach from Google, which to my mind has added some credibility to the solution.

Assuming with the above solution I also included a mobile app key etc (just to stop any mobile hitting the form/API), it seems like it would have the same problem as OAuth in as much that I have to include my app key embedded in the mobile code (that could be decompiled etc).

I also read this article about the Amazon approach (Apparently similar to an OAuth 1 impl), which seems like it could be a reasonable extension to the google proposed solution above and rather than send the token to the server, use it as the key to hash the request data.

I am pretty new to implementing anything in security beyond normal web based user/password security - so would appreciate thoughts on when to use OAuth for mobile apps and if the above two solutions (amazon & google) are fit for purpose of if they have been superceded by oauth2.

So I am reluctant to ask too much of a noob question, as this guy aked about a non-standard approach and got down voted a bunch, but here goes.

I am creating a mobile application which needs to interact on a per-user basis with an API. Having worked on several projects as a client of third-party APIs my initial thought was to go with OAuth. However, I have been thinking about it, and I don't plan to open the API up publicly to other consumers - the only consumer will always only be my mobile app, so was thinking if OAuth is actually the best fit? Or is it overkill?

I then read this article advising on a process from Google, which suggests the following approach for exactly this scenario:

• Embed a webview in your app with a normal web based login form
• on successful login, pass secure cookie to mobile app which has secure token
• use token in future api requests

(assuming all over https etc)

This seems a lot simpler than any OAuth implementation, and could quite easily bee done using Spring Security Filter/authentication chain(My server side code is Java & Spring MVC/Secutiry etc). It seems interesting that is the recommended approach from Google, which to my mind has added some credibility to the solution.

Assuming with the above solution I also included a mobile app key etc (just to stop any mobile hitting the form/API), it seems like it would have the same problem as OAuth in as much that I have to include my app key embedded in the mobile code (that could be decompiled etc).

I also read this article about the Amazon approach (Apparently similar to an OAuth 1 impl), which seems like it could be a reasonable extension to the google proposed solution above and rather than send the token to the server, use it as the key to hash the request data.

I am pretty new to implementing anything in security beyond normal web based user/password security - so would appreciate thoughts on when to use OAuth for mobile apps and if the above two solutions (amazon & google) are fit for purpose of if they have been superceded by oauth2.