Google's OAuth2 requirement that I own the domain
Would someone give me a brief explanation for the necessity of "owning" a domain from which a Javascript app is served that makes OAuth2 calls to a service running on App Engine? I assume this is meant to prevent some security vulnerability. I just can't imagine what, since the Javascript authenticates with the service using the client running in the user's web browser, and the auth flow makes it clear what the user is being asked to allow. What difference does it make where the page comes from?
google-oauth asked Nov 12 at 16:48
Tom Russell
426215
add a comment |
Would someone give me a brief explanation for the necessity of "owning" a domain from which a Javascript app is served that makes OAuth2 calls to a service running on App Engine? I assume this is meant to prevent some security vulnerability. I just can't imagine what, since the Javascript authenticates with the service using the client running in the user's web browser, and the auth flow makes it clear what the user is being asked to allow. What difference does it make where the page comes from?
google-oauth asked Nov 12 at 16:48
Tom Russell
426215
add a comment |
Would someone give me a brief explanation for the necessity of "owning" a domain from which a Javascript app is served that makes OAuth2 calls to a service running on App Engine? I assume this is meant to prevent some security vulnerability. I just can't imagine what, since the Javascript authenticates with the service using the client running in the user's web browser, and the auth flow makes it clear what the user is being asked to allow. What difference does it make where the page comes from?
google-oauth asked Nov 12 at 16:48
Tom Russell
426215
Would someone give me a brief explanation for the necessity of "owning" a domain from which a Javascript app is served that makes OAuth2 calls to a service running on App Engine? I assume this is meant to prevent some security vulnerability. I just can't imagine what, since the Javascript authenticates with the service using the client running in the user's web browser, and the auth flow makes it clear what the user is being asked to allow. What difference does it make where the page comes from?
google-oauth google-oauth asked Nov 12 at 16:48
Tom Russell
426215
asked Nov 12 at 16:48
Tom Russell
426215
asked Nov 12 at 16:48
Tom Russell
426215
asked Nov 12 at 16:48
Tom Russell
426215
asked Nov 12 at 16:48
Tom Russell
426215
426215
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
It does not matter where the authentication request comes from. Your app could be running locally on the client's desktop, mobile, website, etc.
[Technical reasons]:
The endpoint that Google OAuth calls back to provide the token must be transmitted securely to an HTTPS endpoint. If you specify an HTTP endpoint the authorization request will fail. In order to setup SSL on your server you must have a registered domain name. The exception is when you are using http://localhost/ or http://[::1]/ for authorization via a built-in webserver.
[Legal / Political reasons]:
The key is that by owning a domain, Google also has the ability to display information about who is requesting access. This is to protect the end user from fraudulent activites. The information made available to the end user includes:
- The support email address for your website.
- Application Home Page URL.
- Application Privacy Policy URL.
- Application Terms of Service.
In some countries, you must provide written information about how you will use and protect a customer's information by law. If you do not have a website, then this part cannot be accomplished by Google, who is responsible for protecting the end user using Google Accounts for authentication.
answered Nov 13 at 11:45
John Hanley
13.4k2528
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
Nov 15 at 12:27
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53266638%2fgoogles-oauth2-requirement-that-i-own-the-domain%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
It does not matter where the authentication request comes from. Your app could be running locally on the client's desktop, mobile, website, etc.
[Technical reasons]:
The endpoint that Google OAuth calls back to provide the token must be transmitted securely to an HTTPS endpoint. If you specify an HTTP endpoint the authorization request will fail. In order to setup SSL on your server you must have a registered domain name. The exception is when you are using http://localhost/ or http://[::1]/ for authorization via a built-in webserver.
[Legal / Political reasons]:
The key is that by owning a domain, Google also has the ability to display information about who is requesting access. This is to protect the end user from fraudulent activites. The information made available to the end user includes:
- The support email address for your website.
- Application Home Page URL.
- Application Privacy Policy URL.
- Application Terms of Service.
In some countries, you must provide written information about how you will use and protect a customer's information by law. If you do not have a website, then this part cannot be accomplished by Google, who is responsible for protecting the end user using Google Accounts for authentication.
answered Nov 13 at 11:45
John Hanley
13.4k2528
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
Nov 15 at 12:27
add a comment |
It does not matter where the authentication request comes from. Your app could be running locally on the client's desktop, mobile, website, etc.
[Technical reasons]:
The endpoint that Google OAuth calls back to provide the token must be transmitted securely to an HTTPS endpoint. If you specify an HTTP endpoint the authorization request will fail. In order to setup SSL on your server you must have a registered domain name. The exception is when you are using http://localhost/ or http://[::1]/ for authorization via a built-in webserver.
[Legal / Political reasons]:
The key is that by owning a domain, Google also has the ability to display information about who is requesting access. This is to protect the end user from fraudulent activites. The information made available to the end user includes:
- The support email address for your website.
- Application Home Page URL.
- Application Privacy Policy URL.
- Application Terms of Service.
In some countries, you must provide written information about how you will use and protect a customer's information by law. If you do not have a website, then this part cannot be accomplished by Google, who is responsible for protecting the end user using Google Accounts for authentication.
answered Nov 13 at 11:45
John Hanley
13.4k2528
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
Nov 15 at 12:27
add a comment |
It does not matter where the authentication request comes from. Your app could be running locally on the client's desktop, mobile, website, etc.
[Technical reasons]:
The endpoint that Google OAuth calls back to provide the token must be transmitted securely to an HTTPS endpoint. If you specify an HTTP endpoint the authorization request will fail. In order to setup SSL on your server you must have a registered domain name. The exception is when you are using http://localhost/ or http://[::1]/ for authorization via a built-in webserver.
[Legal / Political reasons]:
The key is that by owning a domain, Google also has the ability to display information about who is requesting access. This is to protect the end user from fraudulent activites. The information made available to the end user includes:
- The support email address for your website.
- Application Home Page URL.
- Application Privacy Policy URL.
- Application Terms of Service.
In some countries, you must provide written information about how you will use and protect a customer's information by law. If you do not have a website, then this part cannot be accomplished by Google, who is responsible for protecting the end user using Google Accounts for authentication.
answered Nov 13 at 11:45
John Hanley
13.4k2528
It does not matter where the authentication request comes from. Your app could be running locally on the client's desktop, mobile, website, etc.
[Technical reasons]:
The endpoint that Google OAuth calls back to provide the token must be transmitted securely to an HTTPS endpoint. If you specify an HTTP endpoint the authorization request will fail. In order to setup SSL on your server you must have a registered domain name. The exception is when you are using http://localhost/ or http://[::1]/ for authorization via a built-in webserver.
[Legal / Political reasons]:
The key is that by owning a domain, Google also has the ability to display information about who is requesting access. This is to protect the end user from fraudulent activites. The information made available to the end user includes:
- The support email address for your website.
- Application Home Page URL.
- Application Privacy Policy URL.
- Application Terms of Service.
In some countries, you must provide written information about how you will use and protect a customer's information by law. If you do not have a website, then this part cannot be accomplished by Google, who is responsible for protecting the end user using Google Accounts for authentication.
answered Nov 13 at 11:45
John Hanley
13.4k2528
edited Nov 15 at 20:59
answered Nov 13 at 11:45
John Hanley
13.4k2528
answered Nov 13 at 11:45
John Hanley
13.4k2528
answered Nov 13 at 11:45
John Hanley
13.4k2528
13.4k2528
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
Nov 15 at 12:27
add a comment |
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
Nov 15 at 12:27
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
Nov 15 at 12:27
Comments are not for extended discussion; this conversation has been moved to chat.
– Samuel Liew♦
Nov 15 at 12:27
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53266638%2fgoogles-oauth2-requirement-that-i-own-the-domain%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
