Google OAuth Redirect With Query String Possible? - redirect

Is it possible to pass a parameter to web page via the OAuth redirect URL once the user authenticates? I have specified a parameter on the redirect URL in the Google credentials configuration page but it is not being passed. I'd like to get the value of foo below:
https://example.com/Test?foo=1234

I'm guessing you want to use the query parameter to encode some sort of information that will track the OAuth flow on your end.
In that case, you would need to use the state parameter. You will get the state parameter back as a parameter to your redirect_uri
More information:
https://developers.google.com/identity/protocols/OpenIDConnect#sendauthrequest
https://developers.google.com/identity/protocols/OpenIDConnect#state-param
The state can be useful for correlating requests and responses.
Because your redirect_uri can be guessed, using a state value can
increase your assurance that an incoming connection is the result of
an authentication request. If you generate a random string or encode
the hash of some client state (e.g., a cookie) in this state variable,
you can validate the response to additionally ensure that the request
and response originated in the same browser. This provides protection
against attacks such as cross-site request forgery.

Related

Http Security Token after login

I am using OkHttp to login to a website with username and password. After login any attempt to request a resource is followed with a token=xxxxxxaxx-xxax-xxxa-xxaa-axaxxaxaxxxx in the query path.
I am not certain this is a security token, or just a UUID? It follows the format 8-4-4-4-12 in length and is always lower case alphanumeric.
In order to send new requests to the service I need to acquire/generate token after login. In some cases I note in future requests that both the InstanceId=&token= is passed - where they both pass the same value for token and instanceid.
After login I do not see this token in the of the response headers, it just starts to appear in all future requests.
After login the following URLs are accessed:
portal
launch
htmlnavigator
getCSRFTokenVaue
getUserLocale
createToken
I have confirmed that the token returned by the createToken URL is not the same token that is used in later requests.
The various cookies sent by the server I can user with CookieManager, but where does the security token come from (or usually come from?) - What browser tools might help me beyond reading all the headers and responses.
It is a REST service, and each frame within the browser gets its own token, so difference requests in the same frame use the same token, open a new frame and that frame uses a new token.
The token is passed in the URI.
The web application UI has frames/pages within the main page and opening each new page generates a new token specific to that page
Multiple requests to each frame all send the same token so the tokens are not query authentication (like here)
If more information is required I will update the question but I can not name the system.
It may not be possible to know exactly what the url token is used for, but from what you say, different frames (tabs) in the same browser get different tokens, so it could be a frame specific session id (unusual but might be used to permit multiple sessions in systems where auth is stateless while preventing side-channel attacks) or more likely a form of double-submit CSRF token.

Is it bad to have access token in OAuth redirect URL

I am building an oauth login flow and I am not sure if I have done it wrong because I will need to send the bearer token back via redirect URL, like /oauth2/redirect?token=[TOKEN]. But isn't it not recommended to have token passed along through URL? As it is pointed out in this thread:
Don't pass bearer tokens in page URLs: Bearer tokens SHOULD NOT be passed in page URLs (for example, as query string parameters).Instead, bearer tokens SHOULD be passed in HTTP message headers or message bodies for which confidentiality measures are taken. Browsers, web servers, and other software may not adequately secure URLs in the browser history, web server logs, and other data structures. If bearer tokens are passed in page URLs, attackers might be able to steal them from the history data, logs, or other unsecured locations.
I must have missed something in the whole flow and would like to understand more about this matter. Any input is appreciated!
UPDATE
Might not be correct but this is my understanding after some digging. The three means to pass token:
URL (not preferable)
Auth header
Request body
But under the oauth redirect use case, option 2 and 3 not feasible. So option 1 is the only option available. If really needed, token can be encrypted to ensure security.
I think this only means, that you should not use a GET request when the server requires the token, instead you should use POST or whatever is appropriate. In a GET request the parameters are included in the URL and those can end up in logs or other histories, other request types will send the paramters separat from the request URL.
P.S. BTW if you are not implementing the OAuth server yourself, you won't have to send a redirect url containing the token.
The basic auth header which provides a little extra security as it's required to be through TLS:
In the case of a "Basic" authentication like shown in the figure, the exchange must happen over an HTTPS (TLS) connection to be secure.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication
Also, the headers aren't logged in easy places like browser history.
From the spec,
it SHOULD NOT be used
unless it is impossible to transport the access token in the
"Authorization" request header field or the HTTP request entity-body.
https://www.rfc-editor.org/rfc/rfc6750#section-2.3

Create redirect url in facebook using php

I want to create a facebook redirect url like /fblogin?packgeid=1 in my Codeigniter application
where packgeid is a dynamic value like (1,2,3)
I tried https://localhost/project/fblogin?packgeid={} in facebook Valid OAuth Redirect URIs, but receive an error in facebook response like:
URL Blocked: This redirect failed because the redirect URI is not
whitelisted in the app’s Client OAuth Settings. Make sure Client and
Web OAuth Login are on and add all your app domains as Valid OAuth
Redirect URIs.
You can not use any placeholders or anything like that. If you need to transport any info in your redirect URI via GET parameters, then you would need to enter each any every specific URL explicitly.
The only parameter that is except from this, is the state value. Its main purpose is CSRF protection - but you can use it to transport your own values as well. It should not be a purely static or easily guessable value though (that would stop it from being effective as CSRF protection measure) - so maybe combine a random value and your parameter value, encoding it as JSON, or something like that - that would help you to easily take it apart on the receiving end again.
But do you even need to actually transport this via the redirect URI? Can you not just put packgeid=1 into your session, and then have the script decide what it needs to do after the user is redirect back, based on that?

What is the state parameter used for in Facebook's manual login flow?

In the fb developers docs for oauth authentication api - in the confirming identity section it has this note:
Note that you can also generate your own state parameter and use it with your login request to provide CSRF protection.
Can you help clarify what exactly is the meaning behind this? I mean how will I use a state parameter even if I generate one? Do I encode it as a part of the auth request url? What purpose will it serve even if I did that?
Do I encode it as a part of the auth request url?
Yes. It's also mentioned here in that document, as an optional URL-encoded parameter.
Whatever value you provide will be included in the URL of the redirect response that Facebook returns. It's a way, therefore, for you to pass some value through to your server.
What purpose will it serve even if I did that?
Since the value is simply passed between your app and the server, it's up to you to decide what, if anything, to do with it. The example mentioned is CSRF protection. By including a unique token as the state parameter you could ensure that the call to the server came from your app, rather than some malicious site.
(I don't think this is widely used, though, since the requirement to verify the authorization code or access token deals with most attack vectors.)
That's happens because the FBRLH_state session is not set.
<?php
session_start();
$_SESSION['FBRLH_state'] = $_GET['state'];
...

oauth2 redirect uri. Passing data back to the client

I understand that the reason for the redirect uri is to pass the credentials back to the client, which is fine.
I want to allow programmers to use my client_id to write their own implementation, the problem is that my client_id has associated to it a set amount of redirect_uris, thus if the programmer is making their own implementation they cannot redirect to their own page.
I should thus have a single redirect uri which passes the token back to the client, but how can I achieve this?
Sharing client_ids between different apps is not security best practice. You should be looking in to something like Dynamic Client Registration where each client dynamically registers itself together with its redirect URI to the Authorization Server: https://www.rfc-editor.org/rfc/rfc7592