I want to enter from my web to another, which is located in another server and it has a login.
Until now, I am accessing to this web by apache reverse proxy and a harcorded credentials in my code, but it is not secure.
My idea is make it with some type of authentication token and I found JWT's, but I have absolutely forbidden to use OAuth in the project.
So, anyone could recommend me any solution without OAuth technology?
You can use JWT with a shared secret key in the signature in stead of OAuth.
Related
If an app is interacting with server api over https using post method ( JSON objects ), then there is a danger of api endpoint getting exposed and anyone accessing the api.
Is there a way to make sure that api is called only from the designated app.
I did some research on the web and came to know of:
a. manual credential checking using POST method
b. using json web tokens ( jwt)
However my question is: both of these methods a) & b) would require some kind of username/passwd passing from client app to server ( everytime in a. and only once in b.). Now this username/passwd would need to be hardcoded in apk and it can be easily obtained by anyone by decompiling it. So then how are these methods secure?
I think you're misunderstanding how json web tokens or bearer tokens work. Why would a username and password ever need to be hardcoded? You'd supply the user with an interface that accepts a username and password.
In option a, you'd store these locally after the user supplied their credentials and clear it when they exit the application or log out. This would not be recommended as that's what tokens can be used for. Many frameworks already offer support for JWT out of the box.
If using a token, the user still supplies their username and password to authenticate, the server will return a valid authorization token. From that point forward the auth token is passed with each request.
I would somehow use TLS security ... with digital certificates ... to cryptographically secure the network access to the portal. The app would contain the necessary public certificate, possibly obfuscated, which the server could check to make sure that the access is legitimate. Now, no one can intercept the communications, and they can't spoof it without somehow first extracting the certificate information from the app, which is probably unlikely. Knowing that the supplicant does possess a copy of the necessary public key should be sufficient authentication.
Although we don't usually employ it when we use TLS to get to your friendly neighborhood https web-site, modules like mod_ssl do provide a complete TLS implementation including the ability to require and to verify a client-side security certificate, without possession of which the connection attempt will be refused. This might be an ideal situation for that.
Im trying to use ADFS for SSO on a project. The project is on PHP and Im trying to use OAuth for this.
So what are the steps for setting up ADFS to work with OAuth2? I have no idea about ADFS and cant get any direct guide on OAuth2 settings there.
Thanks a lot.
I see that the question is quite old. But in case if other people will
get here, I have some answer which should be good for March 2019.
Let me start with a general overview.
SSO
SSO could be done with personal Google, Facebook, GitHub, Twitter, Microsoft accounts. After logging in to your account, you can log in to other systems (e.g. WordPress or any other) without password (if other systems integrated with that Identity Provider) and you give the consent (see picture below).
There are services whose main focus is to provide Identity Provider / SSO capabilities (e.g. Okta, Auth0, Google Cloud Identity, Azure Active Directory, AWS IAM).
In the corporate network, the user could be silently signed in based on the AD account without entering credentials via ADFS.
Actually, ADFS supports different authentication protocols like SAML, WS-Fed, and OAuth. But nowadays usually services implement OpenID Connect which works on top of the OAuth 2.0 protocol.
OpenID Connect flows
There is a number of authentication flows that OpenID Connect defines.
Most preferable ones are:
Authorization Code Flow with PKCE (single-page applications, native applications)
If you are using oidc-client-js, you should use response_type=code to use PKCE.
Public native app clients MUST implement the Proof Key for Code Exchange (PKCE RFC7636])
https://www.rfc-editor.org/rfc/rfc8252#section-6
Note: although PKCE so far was recommended as a mechanism to protect native apps, this advice applies to all kinds of OAuth clients, including web applications.
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-12#section-3.1.1
Implicit flow considered as Not recommended:
Clients SHOULD NOT use the implicit grant and any other response type causing the authorization server to issue an access token in the authorization response
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-09
Client credentials flow. For service-to-service communication.
How to configure ADFS?
You can find quite detailed documentation with illustrations for "Native app scenario" at Microsoft Docs: Native client with ADFS.
If you are not using ADFS, you can play with the PKCE flow setup in the playground.
JavaScript frontend
Never store client secrets in public applications like JS frontend or mobile apps. It's not applicable to PKCE flow but just in case.
If you have a modern SPA application (e.g. Angular or React), it means that frontend should have only client_id to enable end-user to obtain the JWT access_token in a browser via ADFS. You don't need any client_secret.
oidc-client-js could help you with that. Make sure that code_verifier is being sent along with a token request (it means that you are using more secured PKCE flow).
PHP backend
And on PHP side you'll need to validate the access token. You can implement the workflow on your own according to that article. But it's better to use OpenID certified library which you can find on this page (not only for PHP):
https://openid.net/developers/certified/
So, for PHP there is only one: phpOIDC.
Authentication
OAuth 2.0 can help you only with authentication (to identify the user's identity).
Most probably you would like to have different permissions for different users. And OpenID Connect implementation in ADFS provides you the ability to map AD groups to token claims. Therefore, you can decode JWT access token on the backend and implement claims-based authorization.
To use JWT claims be sure to properly validate the authenticity of the token and issuer:
Validate JWT signature using public key
Check issuer for the proper issuer (Identity Provider)
Check aud (audience) for the proper client ID
Check exp (expiration timestamp)
Check claims
I have JSON file on my server(on my website).My Iphone and Android app use this JSON.
I would like to hide or secure json files from another websites or app.
Is it possible ?
The most common way to do this it´s by using a Token that signs every WS call.
You can generate this Token in many ways, the most extended it´s by password username encryption.
Users in App sends USER/PASSWORD by SSL secured connection to the server.
Server validates USER/PASSWORD and sends back a token that will be used to sign every call made now on, so the user doesn't have to be sending every time the USER/PASSWORD info.
You can also check how to secure your web service following this SO link.
Best Practices for securing a REST API / web service
Hope it helps. :)
I want to write a hacking protected web services for PHP. Can anyone give me a example how to write that? How to send the authentication headers and how to manage it in the web service?
Many Thanks,
Naveed
First. Never write your own authentication.
Second. Save yourself the pain and serve your service up using https. It opens a lot more options for authentication that are both simple and secure. OAuth 2, Client Side SSL Certificates and even plain old Basic HTTP authentication are options if you are enforcing https. Even if you're doing your own token passing, you'll probably want to do so over SSL.
If https isn't an option, you can consider earlier versions of OAuth that don't require SSL.
Personally, I use a web service to authenticate the user. This web service return the token (a randomized string).
Then the user can call other web services with their specific arguments + the token.
If the token is not valid / expired / ... => I return a message to authenticate
else I return what should be returned :)
Hope this help...
Facebook oAuth requires your secret key? I thought you weren't supposed to share that. Am I using the wrong secret key?
Your secret key is a shared secret between you and Facebook. Thus you can send it over secure channels (such as SSL)
Are you talking about when your program requests an access token? If so, you need to supply the secret you're going to be using so it can be known by Facebook and associated with the access token they're issuing to you. Once you have your access token, you shouldn't have to send your secret to Facebook anymore...just use it to hash your API requests.
The api keys reside in php and you are not supposed to print them anywhere. Just use them to initialize the php facebook api. Here is tutorial i have written to write Facebook apps.
http://www.dreamincode.net/forums/topic/153919-facebook-php-api-and-xfbml-on-iframe/
The answer is, it depends. My understanding is that you are asking about the client_secret or app_secret.
If you are doing server side connection to Facebook, then you use the client_secret. This is the authorization grant type of the oauth protocol.
If you are doing client side connection to Facebook, you don't want to include the client_secret as your code can be decompiled and others can access it, and start interacting with facebook using your credentials. In this instance, you are using the implicit grant type of the oauth protocol. Facebook does not require the client secret in this instance, and in fact, their security page checklist says never to include the client secret:
https://developers.facebook.com/docs/facebook-login/security#checklist
The best (opinion) run down on oauth from a conceptual perspective (rather than nitty gritty code) that I've found is here:
https://stormpath.com/blog/what-the-heck-is-oauth
(I have no association, just like this page).
Hope this helps, D