I got a Jersey Grizzly REST server running. Now i am receiving receiveing an URL from Microsoft with an Access Token however this access token is placed as an parameter after a # Symbol.
https://myURL.com/getToken/pathParam/#access_token=QWERwtrrgertWRDGTGHssef....
When i receive the Request from MS i cant read out the access token by any means, since it is filtered out. Is there a configuration where I can stop this and get the token as a param ?
From the looks of the fragment, it appears you are trying to accomplish an OAuth flow. The problem I see is that you are trying to implement a flow that is meant for the client side (or more correctly, user-agent side), and then trying to access the fragment on the server, which is meant to be interpreted on the user-agent side.
The #access_token.. tells me you are trying to implement the Implicit Grant. This is not recommended if you have access to the more common Authorization Code Grant. I don't know what Microsoft service you are using, but if they offer the Implicit Grant, then they should also offer the Authorization Code Grant, which is actually the most common in all of the Grant types.
If you want to stick with the Implicit Grant, then you will need to actually handle the redirect from the client (user-agent) side, meaning get your hands into writing some Javascript to postback the token to the server. You can see an example here.
I personally wouldn't recommend it. You can have a look at the Jersey OAuth 2.0 client. It will help with implementing the Authorization Code flow.
Related
Looking at the Twilio documentation it seems that "you create [Access Tokens] on your server to verify a user’s identity and grant access to client API features."
Here, Twilio provides a few different ways to programmatically create Access Tokens on the Server side - it looks pretty straight forward.
I am developing an Android app-to-app calling feature and for this I've have been using the Android quickstart-project to go about it. However, for this code, the implementation and execution are done by copying and pasting Access Tokens generated through either the Twilio Console or Twilio-CLI commands.
Say we have our Server set up, a TwiML app and its associated URL, what would be the simplest and most straight-forward way to generate but then retrieve the access token from the Server to the Client app?
From my understanding, you would like to access Twilio API using an access token. In that case, you should have a backend server that stores the access token because you shouldn't store such tokens in the client-side (android app). Your app would send request to your backend which would then use the access code to access the api and forward you the result back.
I need to integrate OpenId connect for SPA application, without having token id in the URL, can we do that?
I'm assuming you have some security concerns with having the ID Token in the URL...
I can see two ways to mitigate risks in this case:
Make sure the OIDC provider redirects to your app using URL fragments instead of via the query string. This ensures that the parameters aren't sent to a server where they might end up in the logs, and should already be the provider's default response mode for implicit flows. If needed you can use response_mode=fragment to enforce it.
You could register a "public" client, but still use the authorization code flow to fetch the ID Token from the token endpoint. In this case you do not present a client_secret to the token endpoint (since the client is public). You could consider using PKCE in this flow as well.
I have a Java Spring driven REST API server connecting with PostgreSQL database and a Spring Web Server in Java that is serving content from the REST API to the client using JavaScript (now browsers, but in the future also mobile apps).
I've read a number of articles and topics how one can secure a REST API, but I haven't been able to make a final decision yet. I don't want to have Basic Authorization, because it doesn't make sense as I would need to store credentials in JavaScript that can be easily accessed and read by anyone entering the webpage and developer console. I'd like not to show any credentials to the end user so I can't keep them on the client's side.
I've read a lot about JWT and almost decided to implement it, but I've heard it has some drawbacks and haven't been so sure since then if it's the option I would like to choose. I know there is also oAuth 1.0 or oAuth 2.0 but I don't know if I want to have something this complicated. I would also like to store hashed user credentials in my own database in order not to be depended to any other credential providers like social media or Google.
Now I'm making another layer on my web server as a proxy hoping that it will allow me to authenticate user on this proxy level using Spring Security and having some kind or cookies or something to authenticate, but I'm not so sure if its doable this way and it increases the respond time, adds complexity and needs me to write controller methods for these endpoints. My architecture now is of the following:
Client (browser) -> Webserver -> REST API server -> db
I've also denied all external connections and allowed only localhost access to REST API on tomcat level so that I'd have to implement the security level only on the web server allowing free information transit between the webserver and REST API as it is not reachable anyway.
Web server and REST API are on the same server running as Tomcat instances.
I'm also not so sure if this kind of architecture will allow me to authenticate mobile app clients through the web server.
I would be very grateful for any piece of advice you would have for me in this matter. I'm not so experienced in security, so I'm a bit lost what I should do. Does this kind of architecture any sense or should I simply ask REST API directly from any type of clients, be it a webpage or a mobile app from different IPs and secure Rest API only? And if I want to secure some subpages of my webpage or parts of mobile app should that be an completely other layer?
Thank you for your help.
You have already gone through OAuth, JWT tokens etc. If you don't want to use them,then you can create your own token based authentication system.(say 'TokenHandler').
How this TokenHandler will work ?
TokenHandler will be like a gateway server i.e your every REST API request will route through this server application. So you will address your confusion of mobile and web application call with a authToken in header. Main responsibility of this server applciation is to accept the token and validate against the database where all token details are maintain. This DB will have information regarding timestamp when token was last used to validate, to decide your validation rule .
How Token will get generated ?
Token can be any random 64 digit alphanumeric string and will be generated and updated in DB during every single login activity. Login webservice returns this token in response body.
What can be rules for validation ?
It can be depending on your business logic. I preferred to keep active session window of 15 mins. Means if you access the webservice you will get active window of 15 more minutes. If you didn't access any service for 15 consecutive minutes then from 16th Minute you will need to login again to access further calls. This part can change according to requirements.
How client side will handle this ?
Client side will store this token and pass this token with every request call. Token Handler will validate and redirects it's request to the application server . So your one token handler can be used to server authentication of multiple applcation servers. This you can achieve by application end point identifer.
I will like to discuss further if you have any questions or suggestions .
Use API Gateway Architecture Pattern for your use case -
http://microservices.io/patterns/apigateway.html .
The API Gateway (The webserver in your question) can act as single entry point for all desktop/mobile clients. You can use either session cookies or jwts to authenticate clients at gateway.
With respect to authentication between gateway and micro services, and between micro services, i would suggest mutual ssl - https://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication. If you are using spring boot, this might help - http://www.opencodez.com/java/implement-2-way-authentication-using-ssl.htm
The problem with IP white-listing approach is that - it's not well suitable for cloud architecture as the IPs might change with every server reboot. Even if you are using dedicated IPs, you should be careful to secure the communication with SSL/TLS, else attackers can easily sniff your traffic.
I am new to OAuth2 concept.I ahve to implement this in my application. This application provides REST APIs. I follwed some tutorial ,done some research and kind of implemented it in working state in my application.
But while doing some search I read about different type of grant_type in OAuth2. I tried to learn about that but didn't get actual differences and which should I use for securing REST APIs.
So I want to know that for grant_type types "password","client_credential"etc which should be used and in which scenario, or which should be used for securing REST APIs?
Also at some places I found that the request for /oauth/token is different.
Some places the Authorization header is given as Basic 'some_encoded_string' .
And at some place it is Bearer 'some_encoded_string'. Whats the difference in these request?
Summarizing this I have 2 question -
For grant_type types "password","client_credential"etc which should be used and in which scenario, or which should be used for securing REST APIs?
What is the difference in ways of requesting token from /oauth/token .
Enlight my knowledge in implementing spring-security-oauth2.
The grant you need to use depends on your use case and the nature of the client application accessing your resources. There isn't a grant that applies a REST APIresource in general. You'd need to provide more information on what the APIs are and how you interact with them.
If a user has to give their permissions for a client to access an API, then you would normally use an "authorization code" grant. If the client accesses the resource directly without the intervention of an end user then it would normally use the "client credentials" grant.
You should avoid using the password grant in most cases, since it means the user has to provide their username and password to the client application. If the application can use another grant, such as authorization code, then that is preferable. A trusted application, such as a native application which the user installs on their computer, would be one situation where the password grant might be used.
A client would normally use "Basic" authentication to access the token endpoint. "Bearer" authentication is use to access a protected resource (such as your API), passing the access token it obtained from the authorization server.
Why do you think you need to use OAuth2 at all? I'm curious since you say you don't understand what the grant types are for. You really need to understand this before you can make a judgement about how you would use OAuth2 or why.
We use the username-password grant to connect our JS client to our REST server. In a way the token returned by oauth/token is our session, as it allows access to the backend for a limited time.
We would like to refresh that session/token every time we make a request to the backend using the token.
I know there is this refresh token issued by the server and I could use it to refresh my token after it has expired.
The thing is: I don't want to make it the client responsiblity to catch token expired exception and re-authenticate or schedule a refresh prior to token expiration. I want the token to refresh itself until it is not used any more for a limited amount of time - just like a session. (I also wouldn't like it to issue a refresh request with every "data" request, though I think I remember reading, a refresh token is only valid once..?!)
Is there a way to do that in spring security or will I have to build some custom implementation of the token store or whatever part I choose?
Since I can't really find an answer (hence the post) I'm thinking: Maybe it is not wise to do this, though I can't think why. If I can steal the token, I can steal the refresh token as well. So I guess I don't really see the point in having a refresh token in the first place..
EDIT
In response to Luke Taylor's answer I'll clearify our use case.
We have a REST server that holds application data like persons. but also provides access to our content management and allows clients to post to facebook. It encapsulates application logic and data storage
We have a fully fledged client application already in place that has its own security layer and justs accesses the data on our REST server via client credentials flow. Who can do what is decided on the client side
We have several medium and small applications like a contact app on facebook that access the data on the REST server also using client credentials
We are now developing a client application using only javascript that will access the REST layer to do all the stuff the big client application does but also needs to provide a means to authenticate individual users and allow multi tenancy. Therefore this new client application uses the username-password grant to authenticate and method level security to authorize the users
So we have a REST server that needs to provide complete access to our trusted application that does its own security stuff and that same server needs to provide access for users of our new multi tenancy javascript client application. In production we will have several REST servers each with its own database but the core will always be the same, so in theory one server should be able to handle all.
I want the token to refresh itself until it is not used any more for a limited amount of time - just like a session
This doesn't really make sense (in an OAuth2 context). The access token is issued by the authorization server, which decides how long it is valid for. It is "used" at a resource server, which may be completely separate from the authorization server, so there is no facility in OAuth2 to connect usage with the lifetime of the token. It would in theory be possible to hack something together which made this work, but it sounds like a bad idea.
If I can steal the token, I can steal the refresh token as well. So I guess I don't really see the point in having a refresh token in the first place..
The access token is used repeatedly and sent by the client to servers other than the authorization server. The refresh token is retained by the client and only sent back to the authorization server. A client also has to authenticate to successfully use a refresh token, so the client id and secret would also have to be compromised.
It's not really clear from your question why you are using OAuth2. You should probably expand your question to clarify this. If there is only one client and a REST server, why not just use something like BASIC auth over HTTPS?
Also, is the client a browser-based app? If so, the username/password grant isn't really suitable for use in an untrusted client.