This is the anti-pattern--the goal of federated identity is to prevent the website/mobile application from ever seeing the users password. If the end app sees the password, you destroy the integrity of your identity platform--how will you ever know if it's the user or the application that is authenticating? Modern federated identity works by having an identity provider present the login page, and then returning an identity assertion back to the website/mobile app. This is accoplished by having the client redirect to the OpenID Provider (OP), and then the OP redirects back to the client (to one of the pre-registered redirect_uri values). If you must send the username and password, look into the OAuth "Resource Owner Password Credential Grant".

Hi Micahel, Thanks for the response. I will be including the token and token refresh as well but i get your point. However the application that is developed has a username & password field already defined. I can get that changed to username only thats not a problem. However i am looking for guidance then how to implement such a thing using REST method. Ofcourse the simplest way would be to send them to a URL which will do the auth and send the response back but how to configure such a thing.

Simple answer: redirect from your website. Asking for the password on your website is bad--it enables your website to see the password which is problematic. You should read my book, [Securing the Perimeter](https://gluu.co/book) Or check out these websites: * [OpenID Connect Website](https://openid.net/connect) * [OpenID Slides from Microsoft](http://wiki.openid.net/w/file/fetch/80030063/OpenID_Connect_Overview_May_5_2014.pdf) * [Minimalist blog from Nat Sakimura](http://nat.sakimura.org/2012/03/31/openid-connect-stripped-down-to-just-authentication)

Thanks