I'd like to use realtime API with server side OAuth2 authentication flow. This would improve the user experience as it forces the user to grant access only once.
Is there a way to "inject" the server side token into the realtime API on the client side?
What Drive API uses to authorize user is access_token. After all OAuth process, you will save credentials which will provide you access_token on server side. You can pass this access_token from server side to client side and use it in javascript client. However, you should make sure that access_token is sent securely to client side, over SSL, or otherwise, it will make serious security issue.
Related
I am trying to achieve the following the scenario but ending up as 403 response.
Client -> sends Cert A -> API Management -> Forwards Cert A -> Backend API (Azure Api App) -> Authenticates the certificate.
Is there is a way to configure API management to forward the incoming certificate to the backend API?
I tried various transformation policies on the incoming request but none of the options worked.
Please suggest.
This is technically not possible since client certificate's private key is never transmitted over wire. So there is no way APIM could use it to authenticate to backend. Even more so since there is no affinity between client connection and backend connection in APIM. Your best option is to send client certificate information in a custom header. You can use ser-header policy to set it at APIM level along with policy expressions to extract client certificate information from request.
With the new authentication-certificate policy (learn.microsoft.com) you may return the certificate as a byte[] coming from a separate send-request response-variable and use it as follows:
<authentication-certificate body="#(context.Variables.GetValueOrDefault<byte[]>("byteCertificate"))" password="optional-certificate-password" />
You could store the password as a secret named value or even get it from the KeyVault by using this snippet:
github.com/Azure/api-management-policy-snippets
I'm attempting to understand how spring boot uses http sessions to manage the oauth authorization code flow.
I understand that after the user submits their credentials via the /login form spring will persist the authentication object so it can be retrieved when the browser is redirected to retrieve the authorization code.
What I dont understand is if the browser needs to sends jsession cookie to the server or http basic authentication header when invoking this flow.
For example if I wanted to initiate the flow manually via curl do I need to specify any special headers ?
It doesn't use HTTP sessions to persist it, the client ID and authorisation code (the code that's passed back to the client app after the user authenticates) is used to identify the authentication object. The authorisation code is then used to obtain the access token.
So:
The client app redirects to the auth server, passing in their client ID.
The user authenticates with their username and password on the auth server , which stores the authentication against the code and client ID and passed the authorisation code back to the calling app as a request param on the redirect URL.
The client app calls back to the auth server, authenticating with it's client ID and secret and passing in the authorisation code. This is then swapped for the access (and possible refresh) token.
If the app needs the user details, the client app calls the user details endpoint authenticating with the access token it now has.
Can't find a way to to upload file directly to bucket instead of submiting file to PHP backend and then forwarding it from backend to bucket.
Is there a way to do this with 2-legged token?
There is but for security reasons the recommended approach is to upload from client to backend and from backend to Forge. The reason is to avoid sending a token with data:write or data:create privileges to the client, which would allow an attacker to mess up with the data present on those buckets.
If you want to do it from client however, the only thing you need to do is to generate a token from your backend, expose an endpoint for your client to access it and perform a REST call from the client using the token and that endpoint: PUT buckets/:bucketKey/objects/:objectName
I'm using the Google client API library for Python. My code is running on an Ubuntu 14.04LTS server.
I have a working Google Compute project, were I created and downloaded a OAuth2.0 token to my server.
I'm trying to write a script that does the following:
Automatically (with no user interaction) authenticate to Google Compute engine.
create a new VM and then perform more actions...
My basic problem is using the OAuth2.0 authentication. It required user approval on a javascript supporting browser, and I want to do it automatically, on my server.
Using my code on my desktop works. A browser page pops up requiring my approval. On my server, I get the following message:
we have detected that your javascript is disabled in your browser
The code segment I use for authentication is:
# authenticate using the OAuth token
client_secret = os.path.join(
os.path.dirname(__file__),
self._oauth_token_path)
# set up a Flow object for the authentication
flow = client.flow_from_clientsecrets(
client_secret,
scope=scope,
message=tools.message_if_missing(client_secret))
# open credential storage path
credential_storage = file.Storage(self._credential_storage_path)
credentials = credential_storage.get()
# get credentails if necessary
if credentials is None or credentials.invalid:
credentials = tools.run_flow(flow, credential_storage, flags)
I read about service account access as a replacement of the regular OAuth2.0 authentication. Does any one know if that's the best way to go? any thoughts on how to do it better?
OAuth 2.0 requires user approval and is not the method to go for if you want to run your code/scripts automatically.
Service accounts are more suitable for this and are supported by the API (https://cloud.google.com/compute/docs/authentication#tools)
You create a service account + key in the developer console and use both to authenticate your application.
I am working on a site that will be using HTML5 sockets to communicate with other server. At that time our users will be logged in , I can't code on other server . I am using PHP at server side. I don't know whether other server has even PHP or not. Client says PKI is a solution. So if user login on our server then I start their communication with HTML5 sockets towards other server to send and receive data. So how can other server authenticate them? I also think that I can have a userkey (like 32hash format) that is sent with HTML5 socket while communication that other server validate and then start working with that user. So client says that hacker can see data over network so I think SSL can work for it. What you guys suggest in such scenario? Please advise
More details:
There will be connection made between our users and another server using apache thrift(will be using TCP), and scenario is that user will login to our site, then we will connect them via HTML5socket to apache thrift on different domain, so in HTML5socket communication we will be forwarding userid to tell thrift server that which user is this, so it is fine. But there are two problems,
As HTML5sockets are at client side then a hacker can create his/her own socket and connect to that server in same way and use some one's id as these are just simple integers.
If we will append some thing in data then a hacker sitting on the network can get it like some hackers do this for session hijacking.
So that's why I am not sure that whether using a sort of SSL or TLS will solve the problem or some PKI or some other digital certificate. So that's why I am asking that here.
thanks
SSL cannot solve this problem. SSL is about creating a secure link between the client and server, it does absolutely nothing to protect the server from a malicious client. SSL cannot solve the problem of SQL Injection or in your case Insecure Direct Object Reference relating to the user id. Judging by this SSL suggestion you probably have never heard of TamperData, which allows you to read/intercept and modify all HTTPS traffic generated by your browser (Including components like flash and JavaScript), BURP is more advanced but does the same thing.
The right way to do this is to have a shared session store that your collection of servers can access. The client is issued a very large random number or cryptographic nonce that it uses as a verification token, which is kind of like a session id. This verification token is used to look up session state in the data store. The communal session store could be as simple as a PHP page that accepts the verification token as a parameter and tells you if its linked to a valid session.
Having 3rd parties issue a callback to verify the session is really the "right way" to do this. It is possible to do this with cryptography, although it is a misuse of cryptography because it introduces the possibility of an attack, where as a callback is absolute. The PHP server can issue the JavaScript client an HMAC token consisting of the user id, a timestamp and the message authentication code. The tricky part is that both the PHP server and any 3rd party will have to share a secret in order to verify the message authentication code. If done properly you can transmit the client can transmit the token, and 3rd parties can verify that the session hasn't expired based on the timestamp and that your servers issued the token (instead of a hacker's forgery) based on the message authentication code.