How does lightning authentication work?
There has been a lot of discussion around speed of development and reusable components and while I do think we get decent marks for that the real promise of lightning components is that for the first time salesforce is opening up access to the presentation layer technology it is using to build customizable applications. The main benefits have not been realized yet externally but I do believe you are starting to see where things are going with lightning extensions, app builder, components from third parties being published on app exchange, etc. we are building an entire ecosystem, a shared ecosystem, where all parties are leveraging the same component-based architecture. The challenge right now is basically were asking you to pardon our dust because the real power lies in the integration of lightning components into various extension points and containers. For example I'm currently working on a "new" feature for lightning called Lightning Out (LO). I put new in quotes because this is merely the productization of an existing service and the underlying aura framework. In fact, for anyone doing Visualforce development over the past few years you've been unaware that one of the most exciting new standard components that salesforce has released in the past 3+ years, analytics:reportChart, is actually a lightning component exposed to Visualforce using the Aura Integration Service! LO Will provide the same capability for any lightning component to be used within VF. Even more exciting is the fact that along with integration into sales forces user experience technology LO also includes cross domain, external web container exposure support and oAuth authentication flows.
Another concept I want to highlight is that using LC does not mean you have to throw away your favorite framework (angular, react, polymer, etc.). We've been working very closely with angular for example to provide the toolkit that makes working with both angular (with ionic layered on top in my specific case) and LC productive and performant. For folks familiar with angular a concrete example of this interoperability comes in the form of a new angular directive, ltng-component, that makes it easy to use lightning components inside of an angular region including passing a litmus test of ng-repeat.
Both LO and LC/Angular support are still being developed but you should start to see these critical technologies in the wild soon.
In summary, LC is supposed to be in the component API, metadata, packaging business and not in competition with your favorite framework. With that said a big part of building a component-based ecosystem is having a reliable versioning system that allows a high level of confidence that in a pushed upgrade, multitenant, multi-author world that salesforce lives in anything that works today will continue to work release over release as push updates are applied. Most if not all existing third-party frameworks do not provide adequate versioning and version emulation support. At best they provide a no conflict mode. Salesforce is going after a much more rigorous world that includes shared libraries better versioned. As a concrete example what happens when you include angular multiple times in the same DOM even if it's the exact same version? now compound that by introducing multiple versions of angular in the same DOM. Finally, move the authors into separate organizations across space and time that are attempting to produce components that integrate in a specific customer as a composite solution. salesforce does not have the solution for this in place but were one of the few that are trying solve it and are positioned with an ecosystem in the enterprise business space ideally suited for this purpose.
There is no difference in terms of authentication. The real benefits of Lightning are short development times and reusable components, particularly for mobile apps. Sharing and permission sets aren't a part of Lightning and still need to be handled indepently through the normal means available within Salesforce.