Pages: [1] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 1 post(s) |
Feyd Rautha Harkonnen
Carpe Noctem. Pandemic Legion
2621
|
Posted - 2015.11.09 18:37:17 -
[1] - Quote
Original thred here.
Essentially, will CCP be providing a dynamic-registration API for OAuth, so that thick-client developers can benefit from the longer-lived refresh tokens coming from 'code' grants, without hard-coding a client-secret in their app binaries?
Thx F
Would you like to know more?
|
|
CCP FoxFour
C C P C C P Alliance
4174
|
Posted - 2015.11.10 09:08:11 -
[2] - Quote
I don't see this happening any time soon if it does. Sorry.
@CCP_FoxFour // Technical Designer // Team Size Matters
Third-party developer? Check out the official developers site for dev blogs, resources, and more.
|
|
Feyd Rautha Harkonnen
Carpe Noctem. Pandemic Legion
2623
|
Posted - 2015.11.10 14:00:07 -
[3] - Quote
What is the recommended approach, embed the client secret in the distributed app binary and use the 'code grant' method, or use the 'implicit grant' method without client secret but force the user to re-authenticate all of the time?
Would you like to know more?
|
Pete Butcher
KarmaFleet Goonswarm Federation
302
|
Posted - 2015.11.10 16:05:52 -
[4] - Quote
Feyd Rautha Harkonnen wrote:What is the recommended approach, embed the client secret in the distributed app binary and use the 'code grant' method, or use the 'implicit grant' method without client secret but force the user to re-authenticate all of the time?
If you're worried about someone taking your secret out of the binary, you're left with implicit grant only. Should you care about it? That's your decision.
http://evernus.com - the ultimate multiplatform EVE trade tool + nullsec Alliance Market tool + Trade Advisor
|
Admiral Blue
Catastrophic Overview Failure Brave Collective
0
|
Posted - 2015.11.10 17:33:25 -
[5] - Quote
Here are two good reads: http://alexbilbie.com/2014/11/oauth-and-javascript/ and https://github.com/kelsin/oauth2-proxy
Even for a thick client you're going to probably have a web server open anyways so redirecting from the OAuth2 proxy to the embedded web server at least ensures your secret stays safe in a hosted environment and not shipped with the client. |
Kali Izia
GoomWaffe Goonswarm Federation
55
|
Posted - 2015.11.10 22:18:44 -
[6] - Quote
It's generally accepted that Oauth client secrets aren't really secret.
Anyone can already identify themselves as your client using an implicit grant. The only thing that having your secret would really do is allow an attacker to use your refresh tokens too, which they likely wouldn't have a large collection of with a client-side app.
Even if you do proxy the requests on your own server, that server would still be susceptible to someone feeding it refresh tokens (or whatever you use to authenticate the user) and getting data back.
Personally I'd just embed the secret and not worry about it. |
|
|
|
Pages: [1] :: one page |
First page | Previous page | Next page | Last page |